RELAX NG Schema

RELAX NG Schema

RELAX NG is the combination of two schema definition languages: RELAX and TREX. This schema definition language was proposed, in its current form at least, in August of 2001. On December 3rd of 2001, the specification committee proposed a formal version 1.0 for RELAX NG. You can find the current specification for RELAX NG at http:// www.oasis-open.org/committees/relax-ng/spec-20011203.html.

One of the major advantages of the RELAX NG schema definition language over its pre-decessors is the ability to specify data types and simultaneously use a simple definition syntax to build a schema. However, before we explore the details for the RELAX NG schema definition language, it’s important that you understand the sources for it: RELAX and TREX.

RELAX

In March of 2000, because of how complex the XML Schema Definition Language was getting, a new schema proposal was generated called Regular Language Description for XML (RELAX). This new schema definition language promised to define RELAX gram-mars using XML syntax, including the data types contained as part of the XML Schema Definition Language, and to be aware of namespaces. According to the RELAX specifi-cation, the RELAX schema definition language combines many features of DTDs with the data types supported by the XML Schema Definition Language. The main idea, as the XML Schema Definition Language was not a formal recommendation at the time RELAX was proposed, was that RELAX schemas could be created using XML syntax and then, when the formal recommendation came around for the XML Schema Definition Language, the schemas created using RELAX could be easily migrated over to the new XML schema standard recommended by the W3C.

The RELAX schema definition language, itself, consists of two parts: RELAX Core and RELAX Namespace. RELAX Core allows schema authors to create XML schemas that define elements and attributes for a single namespace, whereas RELAX Namespace allows authors to develop schemas utilizing multiple namespaces. A sample RELAX schema for the XML document in Listing 6.1 is shown in Listing 6.7.

LISTING 6.7 PurchaseOrder.rlx Contains a Sample RELAX Schema for

PurchaseOrder.xml

<module  moduleVersion=”1.0”  relaxCoreVersion=”1.0”

➥ targetNamespace=””

➥ xmlns=”http://www.xml.gr.jp/xmlns/relaxCore”>

<interface>

<export label=”PurchaseOrder”/> </interface>

<elementRule role=”PurchaseOrder”> <sequence>

<ref label=”ShippingInformation” occurs=”1”/> <ref label=”BillingInformation” occurs=”1”/> <ref label=”Order” occurs=”1”/>

</sequence>

</elementRule>

<elementRule role=”ShippingInformation”> <sequence>

<ref label=”Name” occurs=”1”/> <ref label=”Address” occurs=”1”/> <ref label=”Method” occurs=”1”/>

<ref label=”DeliveryDate” occurs=”1”/> </sequence>

</elementRule>

<elementRule role=”BillingInformation”> <sequence>

<ref label=”Name” occurs=”1”/> <ref label=”Address” occurs=”1”/>

<ref label=”PaymentMethod” occurs=”1”/> <ref label=”BillingDate” occurs=”1”/>

</sequence>

</elementRule>

<elementRule role=”Order”> <sequence>

<ref label=”Product” occurs=”*”/> </sequence>

</elementRule>

<elementRule role=”Address”> <sequence>

<ref label=”Street” occurs=”1”/> <ref label=”City” occurs=”1”/> <ref label=”State” occurs=”1”/> <ref label=”Zip” occurs=”1”/>

</sequence>

</elementRule>

<elementRule  role=”Street”  type=”string”/>

<elementRule  role=”City”  type=”string”/>

<elementRule  role=”State”  type=”string”/>

<elementRule  role=”Zip”  type=”string”/>

<elementRule  role=”Name”  type=”string”/>

<elementRule role=”Product”> <empty/>

</elementRule>

<elementRule  role=”Method”  type=”string”/>

<elementRule  role=”DeliveryDate”  type=”date”/>

<elementRule  role=”PaymentMethod”  type=”string”/>

<elementRule  role=”BillingDate”  type=”date”/>

<tag  name=”ShippingInformation”/>

<tag  name=”BillingInformation”/>

<tag  name=”Order”>

<attribute name=”SubTotal” type=”decimal”/> <attribute name=”ItemsSold” type=”positiveInteger”/>

</tag>

<tag  name=”Product”>

<attribute name=”Name” type=”string”/> <attribute name=”Id” type=”string”/> <attribute name=”Price” type=”decimal”/>

<attribute name=”Quantity” type=”positiveInteger”/> </tag>

<tag  name=”Name”/>

<tag  name=”Street”/>

<tag  name=”City”/>

<tag  name=”State”/>

<tag  name=”Zip”/>

<tag  name=”Address”/>

<tag  name=”Method”/>

<tag  name=”PaymentMethod”/>

<tag  name=”DeliveryDate”/>

<tag  name=”BillingDate”/>

<tag  name=”PurchaseOrder”>

<attribute Name=”Tax” type=”decimal”/> <attribute Name=”Total” type=”decimal”/>

</tag>

</module>

The schema shown in Listing 6.7 may seem a bit strange, but once you understand the grammar behind it, it becomes a very easily understandable schema. The basis for a RELAX schema is that elements are defined using the <elementRule> element. This ele-ment can then reference, using the <ref> element, other elements that have been defined using the <elementRule> element. However, a separate element, <tag> with the same name attribute value as the role attribute on the <elementRule> element contains the attribute declarations for that element. Regardless of whether an element has attributes, it must have a corresponding <tag> element. The jury is still out as to whether this separa-tion of element declarations from attribute declarations causes more complication than a regular DTD or XML Schema.

TREX

In the early part of 2001, another schema definition language proposal emerged, called Tree Regular Expressions for XML (TREX). This schema definition language took the approach of creating “patterns” by which to compare XML instance documents against in order to decide conformity. These patterns represented an unordered collection of attributes and an ordered sequence of elements. A sample TREX schema for the XML document in Listing 6.1 is shown in Listing 6.8.

LISTING 6.8 PurchaseOrder.trex Contains a Sample TREX Schema for PurchaseOrder.xml

<grammar>

<start>

<element name=”PurchaseOrder”> <attribute Name=”Tax”>

<string/>

</attribute>

<attribute Name=”Total”> <string/>

</attribute>

<element name=”ShippingInformation”> <element name=”Name”>

<anyString/>

</element>

<ref  name=”Address”/>

<element name=”Method”> <anyString/>

</element>

<element name=”DeliveryDate”> <anyString/>

</element>

</element>

<element name=”BillingInformation”> <element name=”Name”>

<anyString/>

</element>

<ref  name=”Address”/>

<element name=”PaymentMethod”> <anyString/>

</element>

<element name=”BillingDate”> <anyString/>

</element>

</element>

<element name=”Order”> <attribute name=”SubTotal”>

<anyString/>

</attribute>

<attribute name=”ItemsSold”> <anyString/>

</attribute>

<oneOrMore>

<element name=”Product”> <attribute name=”Name”>

<anyString/>

</attribute>

<attribute name=”Id”> <anyString/>

</attribute>

<attribute name=”Price”> <anyString/>

</attribute>

<attribute name=”Quantity”> <anyString/>

</attribute>

</element>

</oneOrMore>

</element>

</element>

<define name=”Address”> <element name=”Street”>

<anyString/>

</element>

<element name=”City”> <anyString/>

</element>

<element name=”State”> <anyString/>

</element>

<element name=”Zip”> <anyString/>

</element>

</define>

</start>

</grammar>

The schema in Listing 6.8 is a little easier to understand than the RELAX schema listed in Listing 6.7. Truly the TREX schema appears self-explanatory by defining an element’s contents in the traditional hierarchical XML fashion so that it becomes very easy to locate and understand what each element contains. However, the TREX schema defini-tion language has a huge lack of support for any data types other than strings. This can be a major limitation when you’re building an application.

Combining RELAX and TREX

The two different schemas we have just discussed, RELAX and TREX, each have their advantages and disadvantages. RELAX supports the XML Schema data types, but TREX does not; TREX treats content within elements and attributes as strings, the same as a DTD. However, the syntax for TREX is much simpler to understand and implement. As a result, the two schemas were merged into one: RELAX NG. This new schema proposal combines the best of both worlds: support for the XML Schema data types and a simpli-fied schema definition language. You can see the outcome of this combination of schema definition languages in Listing 6.9.

LISTING 6.9 PurchaseOrder.rlxng Contains a Sample RELAX NG Schema for

PurchaseOrder.xml

<grammar>

<start>

<element name=”PurchaseOrder”> <attribute Name=”Tax”>

<data  type=”decimal”  datatypeLibrary=

➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/> </attribute>

<attribute  Name=”Total”>

<data  type=”decimal”  datatypeLibrary=

➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/> </attribute>

<element name=”ShippingInformation”> <element name=”Name”>

<data type=”string” datatypeLibrary= ➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/>

</element>

<ref  name=”Address”/>

<element  name=”Method”>

<data type=”string” datatypeLibrary= ➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/>

<choice>

<value>USPS</value>

<value>UPS</value>

<value>FedEx</value>

<value>DHL</value>

<value>Other</value>

</choice>

</element>

<element  name=”DeliveryDate”>

<data  type=”date”  datatypeLibrary=

➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/> </element>

</element>

<element name=”BillingInformation”> <element name=”Name”>

<data type=”string” datatypeLibrary= ➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/>

</element>

<ref  name=”Address”/>

<element  name=”PaymentMethod”>

<data type=”string” datatypeLibrary= ➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/>

<choice>

<value>Check</value>

<value>Cash</value> <value>Credit Card</value> <value>Debit Card</value> <value>Other</value>

</choice>

</element>

<element  name=”BillingDate”>

<data  type=”date”  datatypeLibrary=

➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/> </element>

</element>

<element name=”Order”> <attribute name=”SubTotal”>

<data type=”decimal” datatypeLibrary= ➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/>

</attribute>

<attribute  name=”ItemsSold”>

<data type=”positiveInteger” datatypeLibrary= ➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/>

</attribute>

<oneOrMore>

<element name=”Product”> <attribute name=”Name”>

<data type=”string” datatypeLibrary= ➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/>

</attribute>

<attribute  name=”Id”>

<data type=”string” datatypeLibrary= ➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/>

</attribute>

<attribute  name=”Price”>

<data type=”decimal” datatypeLibrary= ➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/>

</attribute>

<attribute  name=”Quantity”>

<data type=”positiveInteger” datatypeLibrary= ➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/>

</attribute>

</element>

</oneOrMore>

</element>

</element>

<define name=”Address”> <element name=”Street”>

<data  type=”string”  datatypeLibrary=

➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/> </element>

<element  name=”City”>

<data  type=”string”  datatypeLibrary=

➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/> </element>

<element  name=”State”>

<data  type=”string”  datatypeLibrary=

➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/> </element>

<element  name=”Zip”>

<data  type=”string”  datatypeLibrary=

➥ ”http://www.w3.org/2001/XMLSchema-datatypes”/> </element>

</define>

</start>

</grammar>

You can see many similarities between the schema in Listing 6.9 and the TREX schema in Listing 6.8. Most of the element definitions and grammar remain the same between TREX and RELAX NG, but with one important addition: the <data> element. This is probably the single biggest reason for the creation of RELAX NG. Previously in TREX, a schema author was very limited in data type representation. Now, with the new <data> element, the RELAX NG schemas can support data types other than strings. In addition, due to the inclusion of the datatypelibrary attribute on the <data> element, the data types do not necessarily have to belong to the XML Schema Definition Language; they can come from anywhere.

By adopting the TREX-style schema definition, RELAX NG removes the cumbersome language associated with the RELAX schema definition language. Now, rather than having to specify both <elementRule> and <tag> elements to define an element’s contents, you can accomplish everything within the <element> element.

So, what is it about Listing 6.9 that, without one necessarily knowing anything about the RELAX NG language itself, makes it intuitive to understand? For one, now that cardinal-ity is expressed using element definitions, it becomes very clear as to how many of a particular element may appear within another. Remember that in the W3C schema rec-ommendation, cardinality is expressed using the minOccurs and maxOccurs attributes. However, at the same time, you can no longer specify, say, that an element must occur between two to five times within another element, which is a major limiting factor in the RELAX NG schema recommendation.