The Specific ElementFormDefault Schema Attribute

Greetings, I am Michael Dupre. Thanks for visiting my '5 minute XML' series specifically where I provide you with normal byte size guides.

Today's current theme is ideal for people who're new to XML.

As part of “XML Schema - Overview” (5 Minute XML #7), I introduced the necessity for a schema definition language. I explained the essential syntax intended for indicating the namespace in the schema document and W3C URI (for referencing elements and attributes not defined inside the targetNamespace).

In closing I described the following schema attribute: <xs:schema elementFormDefault="qualified" ...>.

In this article, I hope to explain the key reason why and just how the following attribute must be used and also what influences it brings to bear.

To put it differently an XML schema is regarded as a group of rules or specification if you'd prefer, which a developer might make use of to explain the structure of an XML document.

For example with a database schema will explain the data that may be contained in a database (table structure, data types, etc.) An XML Schema is much the same for an XML document, it is effectively a rule set.

A schema by itself is actually composed of components coming from several schemas each in its own namespace. A schema designer needs to make a decision whether to reveal or conceal these namespaces towards the instance doc. The elementFormDefault schema attribute allows them to do just this.

Setting elementFormDefault="unqualified" (the default) will hide (or localise) the namespaces, in contrast to setting it to "qualified" will expose the namespaces outlined around the schema to the instance document.

Such as the schema listed below describes a car which generally sources components through two to three other schemas. The chassis, wheels and interior are all produced by independent suppliers.

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>

Bear in mind the import elements. These allow entry to elements via the totally different manufacturers. Notice as well that the schema attribute elementFormDefault is actually set to unqualified.

This process conceals the many different manufacturers’ namespaces from any instance doc. This sort of an instance file may well look something similar to :

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>

Purely the car root element namespace qualifier is usually exposed in the instance document, above. The different car makers supplying the numerous components are now hidden or ‘localised’ to the schema definition. The instance record doesn’t worry itself with where exactly the components are taken from. Only that they are obtainable.

If, on the other hand, elementFormDefault was in fact set to qualified we would certainly have a different story…

These will certainly be discussed in another 5 Minute XML tutorial.

An abundance of data is available concerning XML people who want to understand more. For the definitive guide, visit .W3.org.

Lets hope the aforementioned is beneficial to another person out there. A lot more content might be on its way shortly.

Additional articles about xml

About the author

Michael Dupre is an veteran authority in XML development and even XML standards and has plenty of working an understanding of xml data and practical know how with download xml.

Please Rate This Article

Select Rating Excellent Very Good Interesting Fair Could Use Improvement

Number of ratings: 0
Rating: 0