The Specific Element Form Default Schema Attribute
View PDF | Print View
by: michaeldupre
Total views: 16
Word Count: 727
Date: Mon, 5 Sep 2011 Time: 2:11 AM
Hi there, my name is Michael Dupre. This is my '5 minute XML' series the place where I provide you regular byte size guides.
The current theme is ideal for individuals that are novices at XML.
In “XML Schema - Overview” (5 Minute XML #7), I revealed the need for a schema definition language. I explained the fundamental syntax intended for indicating the namespace on the schema document and W3C URI (for referencing elements and attributes not defined from the targetNamespace).
In conclusion I referenced the following schema attribute: <xs:schema elementFormDefault="qualified" ...>.
In this article, I'm hoping to explain why and exactly how this particular attribute must be used not to mention just what influences it brings to bear.
Put simply an XML schema is seen as a set of rules or specification if you'd prefer, that a coder would use to explain the structure of an XML document. As an example with a database schema will describe the data that could be found in a database (table structure, data types, etc.) An XML Schema will be much the same for an XML document, it is effectively a rule set.
A schema on its own is actually comprised of components coming from various schemas each in its own namespace. A schema designer has to make a decision whether or not to expose or maybe obscure these namespaces to the instance record. The elementFormDefault schema attribute allows them to do just this.
Setting elementFormDefault="unqualified" (the default) will hide (or localise) the namespaces, while setting it to "qualified" is going to expose the namespaces outlined in the schema to the instance document.
For example the schema just below describes a car which sources components coming from two to three other schemas. The chassis, wheels and interior are generally produced from different brands.
Car.xsd
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="*.w3.org/2001/XMLSchema"
targetNamespace="*.car.org"
xmlns="*.car.org"
xmlns:ford="*.ford.com"
xmlns:toyota="*.toyota.com"
xmlns:audi="*.audi.com"
elementFormDefault="unqualified">
<xsd:import namespace="*.ford.com"
schemaLocation="Ford.xsd"/>
<xsd:import namespace="*.toyota.com"
schemaLocation="Toyota.xsd"/>
<xsd:import namespace="*.audi.com"
schemaLocation="Audi.xsd"/>
<xsd:element name="camera">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="chassis" type="Ford:chassis"/>
<xsd:element name="wheels" type="Toyota:wheels"/>
<xsd:element name="interior" type="Audi:interior"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Take note of the import elements. These allow for entry to elements through the different manufacturers. Word as well that the schema attribute elementFormDefault will be set to unqualified. This process hides the different manufacturers’ namespaces from any instance file. This type of an instance record might look and feel a little something for example :
Car.xml
<?xml version="1.0"?>
<my:car xmlns:my="*.car.org" xmlns:xsi="*.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="*.car.org Car.xsd">
<chassis>
<description>
Ford F-Series F-150 Regular Cab 2WD
</description>
</chassis>
<wheels alloys="true">
<tyres>Pirelli P3000</tyres>
</wheels>
<interior>
<seatCoverMaterial>leather</seatCoverMaterial>
</interior>
</my:camera>
Only the car root element namespace qualifier is totally exposed in the instance document, above. The different car makers producing the actual various components are right now hidden or ‘localised’ to the schema definition. The instance file doesn’t worry itself with the place where the components are taken from. Only that they are obtainable.
However, if, on the other hand, elementFormDefault has been set to qualified we would have a different story…
These will probably be introduced from another 5 Minute XML course.
An abundance of data is available relating to XML for individuals who want to know more. For the definitive guide, visit www.W3.org.
I hope the above mentioned is beneficial to someone out there. Much more content will probably be coming in the near future.
About the Author
Michael Dupre is truly an skilled authority in XML programming and XML standards and possesses loads of working expertise in XML Editor and also sensible know how with XML Schema Editor.
