Doing More With XML Schemas (part 2) - Going Local
(Page 6 of 6 )
You'll remember, from the first article in this series, that the XML Schema specification allows you to split up schema definitions across multiple files, and include one file within another using the <xsd:include> element. This not only helps in logically separating base and derived definitions, it also makes your code cleaner and easier to maintain.
In case you're using a schema published by an external party, it's quite possible that you may need to make changes to it in order to tailor it to your specific requirements. Making changes to the original schema definitions is not always the best way to accomplish this task; sometimes, it's more logical to leave the original schema definitions as is, and simply over-ride them with new definitions where needed.
The XML Schema specification allows you to do this via the <xsd:redefine> element, which makes it possible to easily redefine an existing schema definition. In order to illustrate this, let's return to the last example in the first part of this article, in which I split up my schema definitions into "base-defs.xsd", which contained the base definitions,
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--
base definitions -->
<xsd:complexType name="starWarsEntity">
<xsd:sequence>
<xsd:element
name="name" type="xsd:string"/>
<xsd:element name="species" type="xsd:string"/>
<xsd:element
name="language" type="xsd:string"/>
<xsd:element name="home" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element
name="gallery">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="character"
type="starWarsEntity" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
and "derived-defs.xsd", which referenced "base-defs.xsd" and contained the extensions.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--
include base types-->
<xsd:include schemaLocation="base-defs.xsd"></xsd:include>
<!--
derived types -->
<xsd:complexType name="Human">
<xsd:complexContent>
<xsd:extension
base="starWarsEntity">
<xsd:sequence>
<xsd:element name="gender"
type="xsd:string"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType
name="Jedi">
<xsd:complexContent>
<xsd:extension base="Human">
<xsd:sequence>
<xsd:element
name="midichlorian-count"
type="xsd:integer"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType
name="JediMaster">
<xsd:complexContent>
<xsd:restriction base="Jedi">
<xsd:sequence>
<xsd:element
name="name"
type="xsd:string"/>
<xsd:element name="species"
type="xsd:string"/>
<xsd:element
name="language"
type="xsd:string"/>
<xsd:element name="home"
type="xsd:string"/>
<xsd:element
name="gender"
type="xsd:string"/>
<xsd:element
name="midichlorian-count">
<xsd:simpleType>
<xsd:restriction
base="xsd:integer">
<xsd:minInclusive
value="10000" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
...
and so on ...
</xsd:schema>
Finally, my XML document instance itself referenced the schema definitions in
"derived-defs.xsd".
<?xml version="1.0" encoding="UTF-8"?>
<gallery xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="derived-defs.xsd">
...
</gallery>
Now, let's assume I wanted to redefine the new "JediMaster" type included in
"derived-defs.xsd" to include one more attribute. I could put this (re)definition in a file called "local-defs.xsd",
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--
include and redefine derived types-->
<xsd:redefine schemaLocation="derived-defs.xsd">
<xsd:complexType
name="JediMaster">
<xsd:complexContent>
<xsd:extension base="JediMaster">
<xsd:sequence>
<xsd:element
name="weapon"
type="xsd:string"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:redefine>
</xsd:schema>
and reference this new file in my XML document instance.
<?xml version="1.0" encoding="UTF-8"?>
<gallery xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="local-defs.xsd">
<character
xsi:type="JediMaster">
<name>Luke Skywalker</name>
<species>Human</species>
<language>Basic</language>
<home>Tatooine</home>
<gender>Male</gender>
<midichlorian-count>38000</midichlorian-count>
<weapon>lightsaber</weapon>
</character>
...
and so on ...
</gallery>
The XML validator will now use the new definition of the "JediMaster" class when
validating this document instance, rather than the original definition in "local-defs.xsd". Other types may be redefined in a similar manner.
This ability to selectively redefine schema elements makes it possible to easily "localize" an externally-provided set of schema definitions to specific needs, without damaging or altering the original.
And that's about it for the moment. In the next part of this article, I'll be looking at uniqueness, keys and references. Lotsa good stuff ahead - so make sure you tune in!
Note: All examples in this article have been tested on Linux/i586. Examples are illustrative only, and are not meant for a production environment. Melonfire provides no warranties or support for the source code described in this article. YMMV!
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
