Dead Formats: XDR, DSD, and DCD

Dead Formats: XDR, DSD, and DCD

Along the way to the final XML Schema recommendation given by the W3C, many other schema formats were proposed. Some of these proposals gave the W3C ideas on what needed to be included in an “all-inclusive” and robust schema definition language.

For example, some of these proposals build or solve problems in other schema proposals. There has been a long-recognized need to have way in which to define a schema for an XML document using XML syntax. As a result, many proposals were created and sub-mitted to the W3C, and you’ll see aspects from some of these proposals in the formal recommendation by the W3C for the XML Schema Definition Language.

Still, some companies created their own versions because they needed an immediate schema definition language and couldn’t wait for the W3C to complete its formal recom-mendation on the XML Schema Definition Language. However, these formats, although still supported by many systems, will most likely be phased out in favor of the new W3C XML Schema Definition Language, and they are now considered inactive, on hold, or outright “dead.” The major formats that we will concentrate on are the XML Data Reduced, Document Structure Definition, and Document Content Description languages, all of which helped to contribute to the formal XML Schema recommendation.

XML Data Reduced (XDR) Schema

In 1998, a proposal was created based on the XML-Data submission to the W3C called XML Data Reduced (XDR). This proposal refined the ideas and concepts found in the XML-Data submission down to a more manageable size in the hopes that faster progress toward adopting a formal schema definition language would be made. The main purpose of this proposal was to create a schema definition language by which elements and attrib-utes of an XML document could be defined using XML syntax rather than using DTDs, which were recognized as being inadequate. The proposal for XDR can be found at http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm.

Going back to our online grocery store order example in Listing 6.1, the XDR schema for that sample document could appear as shown in Listing 6.3. Note the use of the word could. As there are many different ways to reach the same definition, this is one example of how this schema might be defined; the details regarding how this schema is con-structed could vary from author to author. For instance, the <AttributeType> elements could be declared globally rather than locally. This doesn’t change the overall results of this schema, however.

LISTING 6.3 PurchaseOrder.xdr Contains an XDR Schema for PurchaseOrder.xml

<Schema  name=”Untitled-schema”

➥ xmlns=”urn:schemas-microsoft-com:xml-data”

➥ xmlns:dt=”urn:schemas-microsoft-com:datatypes”>

<ElementType name=”Address” model=”closed” content=”eltOnly” ➥ order=”seq”>

<element  type=”Street”  minOccurs=”1”  maxOccurs=”1”/>

<element type=”City” minOccurs=”1” maxOccurs=”1”/> <element type=”State” minOccurs=”1” maxOccurs=”1”/> <element type=”Zip” minOccurs=”1” maxOccurs=”1”/>

</ElementType>

<ElementType name=”BillingDate” model=”closed” ➥ content=”textOnly” dt:type=”date”/>

<ElementType name=”BillingInformation” model=”closed” ➥ content=”eltOnly” order=”seq”>

<element type=”Name” minOccurs=”1” maxOccurs=”1”/> <element type=”Address” minOccurs=”1” maxOccurs=”1”/> <element type=”PaymentMethod” minOccurs=”1” maxOccurs=”1”/> <element type=”BillingDate” minOccurs=”1” maxOccurs=”1”/>

</ElementType>

<ElementType name=”City” model=”closed” content=”textOnly” ➥ dt:type=”string”/>

<ElementType name=”DeliveryDate” model=”closed” ➥ content=”textOnly” dt:type=”date”/>

<ElementType name=”Method” model=”closed” content=”textOnly” ➥ dt:type=”string”/>

<ElementType name=”Name” model=”closed” content=”textOnly” ➥ dt:type=”string”/>

<ElementType name=”Order” model=”closed” content=”eltOnly” ➥ order=”seq”>

<AttributeType name=”SubTotal” dt:type=”fixed.14.4” ➥ required=”yes”/>

<AttributeType name=”ItemsSold” dt:type=”i1” ➥ required=”yes”/>

<attribute type=”SubTotal”/> <attribute type=”ItemsSold”/>

<element type=”Product” minOccurs=”1” maxOccurs=”*”/> </ElementType>

<ElementType name=”PaymentMethod” model=”closed” ➥ content=”textOnly” dt:type=”string”/>

<ElementType name=”Product” model=”closed” content=”empty”> <AttributeType name=”Name” dt:type=”string” required=”yes”/> <AttributeType name=”Id” dt:type=”string” required=”yes”/> <AttributeType name=”Price” dt:type=”fixed.14.4”

➥ required=”yes”/>

<AttributeType  name=”Quantity”  dt:type=”i1”  required=”yes”/>

<attribute type=”Name”/> <attribute type=”Id”/> <attribute type=”Price”/> <attribute type=”Quantity”/>

</ElementType>

<ElementType name=”PurchaseOrder” model=”closed” ➥ content=”eltOnly” order=”seq”>

<AttributeType name=”Tax” dt:type=”fixed.14.4” ➥ required=”yes”/>

<AttributeType name=”Total” dt:type=”fixed.14.4” ➥ required=”yes”/>

<AttributeType  name=”xmlns”  dt:type=”string”/>

<attribute type=”Tax”/> <attribute type=”Total”/> <attribute type=”xmlns”/>

<element type=”ShippingInformation” minOccurs=”1” ➥ maxOccurs=”1”/>

<element type=”BillingInformation” minOccurs=”1” ➥ maxOccurs=”1”/>

<element type=”Order” minOccurs=”1” maxOccurs=”1”/> </ElementType>

<ElementType name=”ShippingInformation” model=”closed” ➥ content=”eltOnly” order=”seq”>

<element type=”Name” minOccurs=”1” maxOccurs=”1”/> <element type=”Address” minOccurs=”1” maxOccurs=”1”/> <element type=”Method” minOccurs=”1” maxOccurs=”1”/> <element type=”DeliveryDate” minOccurs=”1” maxOccurs=”1”/>

</ElementType>

<ElementType name=”State” model=”closed” content=”textOnly” ➥ dt:type=”string”/>

<ElementType name=”Street” model=”closed” content=”textOnly” ➥ dt:type=”string”/>

<ElementType name=”Zip” model=”closed” content=”textOnly” ➥ dt:type=”i4”/>

</Schema>

So, what can you tell from Listing 6.3? Well, for one, you see many similarities between an XDR schema and the W3C schema shown in Listing 6.2. Attributes are defined separately and then declared within the element or elements in which they are needed. Also, elements are defined separately and then placed inside the parent elements’ defini-tions, as needed. Also, you can see that XDR supports an intrinsic set of data types simi-lar to the ones supported by the W3C schema. As such, it makes sense then that some of the standards developed for XML Data Reduced schemas made it into the final recom-mendation by the W3C for the XML Schema Definition Language.

However, upon closer examination of Listings 6.2 and 6.3, we can quickly identify some major differences. For one, there is one way in which to define all element definitions within an XDR schema: the <ElementType> element. Whereas in the XSD schema, you can choose between <complexType> and <simpleType>, depending on the content you expect the element to hold. Also, you’ll notice that to include a declaration of some data type in the XDR schema, you must use the type attribute from the urn:schemas-microsoft-com:datatypes namespace. You’ll also notice that there’s no support for an anonymous type declaration within an XDR schema: You must still create an <ElementType> element to define the element’s contents, although you can declare it within the parent element, in which case it is referred to as a local type definition. Lastly, although you cannot tell simply from comparing the two schemas, an XDR schema does not support inheriting elements and attributes from another schema.

Document Structure Description (DSD) Schema

In 1999, AT&T Labs in New Jersey and BRICS at the University of Aarhus, Denmark collaborated to create the proposal for the Document Structure Description (DSD) lan-guage. The DSD language came about from a need to describe XML documents to Web programmers with a very limited background in computer science. The DSD language was designed to further the W3C-sponsored XML technologies, such as XSL Transformations (XSLT) and Cascading Style Sheets (CSS).

The benefit, at the time, was that DSD did not require specialized knowledge of XML or SGML because the technology was based on general and familiar concepts that allowed for stronger XML document descriptions than were possible with a DTD or the XML Schema proposal as it existed at the time; remember, the XML Schema Definition Language was not made into a formal recommendation until 2001. More complete information on this schema format can be found at http://www.brics.dk/DSD/.

Looking back to our online grocery store order example in Listing 6.1, the DSD schema for that sample document could appear as shown in Listing 6.4. (Note the use of the word could.) Again, different authors may define the same structure for an XML document slightly differently.

<DSD  IDRef=”PurchaseOrder”  DSDVersion=”1.0”>

<Title>DSD for PurchaseOrder.xml</Title> <Version>1.0</Version>

<Author>Travis  Vandersypen</Author>

<ElementDef  ID=”PurchaseOrder”>

<AttributeDecl Name=”Tax”> <OneOrMore>

<CharRange Start=”0” End=”9”/> </OneOrMore>

</AttributeDecl>

<AttributeDecl Name=”Total”> <OneOrMore>

<CharRange Start=”0” End=”9”/> </OneOrMore>

</AttributeDecl>

<OneOrMore>

<Sequence>

<Element IDRef=”ShippingInformationType”/> <Element IDRef=”BillingInformationType”/> <Element IDRef=”OrderType”/>

</Sequence>

</OneOrMore>

</ElementDef>

<ElementDef ID=”CityType” Name=”City”> <Content>

<StringType/>

</Content>

</ElementDef>

<ElementDef ID=”StateType” Name=”State”> <Content>

<StringType/>

</Content>

</ElementDef>

<ElementDef ID=”StreetType” Name=”Street”> <Content>

<StringType/>

</Content>

</ElementDef>

<ElementDef ID=”ZipType” Name=”Zip”> <Content>

<StringType/>

</Content>

</ElementDef>

<ElementDef ID=”AddressType” Name=”Address”> <Sequence>

<Element IDRef=”StreetType”/> <Element IDRef=”CityType”/> <Element IDRef=”StateType”/> <Element IDRef=”ZipType”/>

</Sequence>

</ElementDef>

<ElementDef ID=”BillingDateType” Name=”BillingDate”> <Content>

<StringType/>

</Content>

</ElementDef>

<ElementDef ID=”PaymentMethodType” Name=”PaymentMethod”> <Content>

<StringType/>

</Content>

</ElementDef>

<ElementDef ID=”BillingInformationType” ➥ Name=”BillingInformation”>

<Sequence>

<Element IDRef=”NameType”/> <Element IDRef=”AddressType”/> <Element IDRef=”PaymentMethodType”/> <Element IDRef=”BillingDateType”/>

</Sequence>

</ElementDef>

<ElementDef ID=”DeliveryDateType” Name=”DeliveryDate”> <Content>

<StringType/>

</Content>

</ElementDef>

<ElementDef ID=”DeliveryMethodType” Name=”Method”> <Content>

<StringType/>

</Content>

</ElementDef>

<ElementDef ID=”NameType” Name=”Name”> <Content>

<StringType/>

</Content>

</ElementDef>

<ElementDef ID=”ShippingInformationType” ➥ Name=”ShippingInformation”>

<Sequence>

<Element IDRef=”NameType”/> <Element IDRef=”AddressType”/>

<Element IDRef=”DeliveryMethodType”/> <Element IDRef=”DeliveryDateType”/>

</Sequence>

</ElementDef>

<ElementDef ID=”OrderType” Name=”Order”> <AttributeDecl Name=”SubTotal”>

<OneOrMore>

<CharRange Start=”0” End=”9”/> </OneOrMore>

</AttributeDecl>

<AttributeDecl Name=”ItemsSold”> <OneOrMore>

<CharRange Start=”0” End=”9”/> </OneOrMore>

</AttributeDecl>

<OneOrMore>

<Element IDRef=”ProductType”/> </OneOrMore>

</ElementDef>

<ElementDef  ID=”ProductType”  Name=”Product”>

<AttributeDecl  IDRef=”Name”/>

<AttributeDecl Name=”Id”> <OneOrMore>

<AnyChar/>

</OneOrMore>

</AttributeDecl>

<AttributeDecl Name=”Price”> <OneOrMore>

<CharRange Start=”0” End=”9”/> </OneOrMore>

</AttributeDecl>

<AttributeDecl  Name=”Quantity”>

<OneOrMore>

<CharRange  Start=”0”  End=”9”/>

</OneOrMore>

</AttributeDecl>

</ElementDef>

</DSD>

You can see that the major difference in Listing 6.4 from the sample W3C schema in Listing 6.2 is that cardinality can be expressed via special elements such as <OneOrMore> and <ZeroOrMore>. Furthermore, strings have special element type definitions using the <StringType> element, by which an author can specify that an element contains string content. Again, however, you see the same basic trend with the W3C schema repeated here: Elements have their definitions declared separately from where they are actually used and placed within a parent element. Also, the DSD schema definition language uses a grammar-based approach to indicate how conforming XML documents

should be structured.

Upon close inspection, though, you can see some major limitations with the DSD language. For one, it makes the assumption that everything is a string data type. Although that may be true in a sense, it’s rather limiting when you wish to represent data that possesses a different data type other than string. For instance, does it make sense to define an element or attribute that should contain a monetary value as some string representation of that? Not really. And the DSD also does not provide support for inheriting elements and attributes from other schemas.

Document Content Description (DCD) Schema

In 1998, IBM, Microsoft, and Textuality collaborated and created a proposal which was then submitted to the W3C to create a new standard by which rules governing the struc-ture and content of XML documents could be represented in an XML syntax. This submission was titled the Document Content Description (DCD). The DCD standard incorporates a subset of the XML-Data Submission and expresses it in a way consistent with the W3C Resource Description Framework (RDF). The DCD standard was intended to be a viable option to a DTD. However, with the formal recommendation of the XML Schema Definition Language, this proposal, like so many others, has become obsolete. The submission made to the W3C can be found at http://www.w3.org/TR/NOTE-dcd.

As an example of a Document Content Description schema, we’ll again use the online grocery store example in Listing 6.1 as the sample document we’ll attempt to describe. The resulting DCD schema is shown in Listing 6.5.

LISTING 6.5 PurchaseOrder.dcd Contains a DCD Schema for PurchaseOrder.xml

<DCD  xmlns:RDF=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”>

<ElementDef Type=”Address” Root=”True” Content=”Closed” ➥ Model=”Elements”>

<Group RDF:Order=”Seq”> <Element>Street</Element> <Element>City</Element> <Element>State</Element> <Element>Zip</Element>

</Group>

</ElementDef>

<ElementDef  Type=”BillingDate”  Root=”True”  Content=”Closed”

➥ Model  Model=”Data”  Datatype=”date”/>

<ElementDef Type=”BillingInformation” Root=”True” ➥ Model Content=”Closed” Model=”Elements”>

<Group RDF:Order=”Seq”> <Element>Name</Element> <Element>Address</Element> <Element>PaymentMethod</Element> <Element>BillingDate</Element>

</Group>

</ElementDef>

<ElementDef  Type=”City”  Root=”True”  Content=”Closed”

➥ Model  Model=”Data”  Datatype=”string”/>

<ElementDef  Type=”DeliveryDate”  Root=”True”  Content=”Closed”

➥ Model  Model=”Data”  Datatype=”date”/>

<ElementDef  Type=”Method”  Root=”True”  Content=”Closed”

➥ Model  Model=”Data”  Datatype=”string”/>

<ElementDef  Type=”Name”  Root=”True”  Content=”Closed”

➥ Model  Model=”Data”  Datatype=”string”/>

<ElementDef  Type=”Order”  Root=”True”  Content=”Closed”

➥ Model  Model=”Elements”>

<AttributeDef  Name=”SubTotal”  Datatype=”fixed.14.4”

➥ Model  Occurs=”Required”/>

<AttributeDef  Name=”ItemsSold”  Datatype=”i1”

➥ Model  Occurs=”Required”/>

<Group RDF:Order=”Seq” Occurs=”OneOrMore”> <Element>Product</Element>

</Group>

</ElementDef>

<ElementDef  Type=”PaymentMethod”  Root=”True”  Content=”Closed”

➥ Model  Model=”Data”  Datatype=”string”/>

<ElementDef  Type=”Product”  Root=”True”  Content=”Closed”

➥ Model  Model=”Empty”>

<AttributeDef  Name=”Name”  Datatype=”string”

➥ Model  Occurs=”Required”/>

<AttributeDef  Name=”Id”  Datatype=”string”

➥ Model  Occurs=”Required”/>

<AttributeDef  Name=”Price”  Datatype=”fixed.14.4”

➥ Model  Occurs=”Required”/>

<AttributeDef  Name=”Quantity”  Datatype=”i1”

➥ Model Occurs=”Required”/> </ElementDef>

<ElementDef  Type=”PurchaseOrder”  Root=”True”  Content=”Closed”

➥ Model  Model=”Elements”>

<AttributeDef  Name=”Tax”  Datatype=”fixed.14.4”

➥ Model  Occurs=”Required”/>

<AttributeDef  Name=”Total”  Datatype=”fixed.14.4”

➥ Model  Occurs=”Required”/>

<Group RDF:Order=”Seq”> <Element>ShippingInformation</Element> <Element>BillingInformation</Element> <Element>Order</Element>

</Group>

</ElementDef>

<ElementDef Type=”ShippingInformation” Root=”True” ➥ Model Content=”Closed” Model=”Elements”>

<Group RDF:Order=”Seq”> <Element>Name</Element> <Element>Address</Element> <Element>Method</Element> <Element>DeliveryDate</Element>

</Group>

</ElementDef>

<ElementDef  Type=”State”  Root=”True”  Content=”Closed”

➥ Model  Model=”Data”  Datatype=”string”/>

<ElementDef  Type=”Street”  Root=”True”  Content=”Closed”

➥ Model  Model=”Data”  Datatype=”string”/>

<ElementDef Type=”Zip” Root=”True” Content=”Closed” ➥ Model Model=”Data” Datatype=”i4”/>

</DCD>

From the schema definition in Listing 6.5, you can see that many similarities exist among a DCD schema, an XDR schema, and a W3C XML Schema. All three have demonstrated that element contents are defined separately and then referenced elsewhere, where they are needed; the same goes for attributes. Plus, all three take the basic approach of building from the smallest piece outward; that is to say that the simplest pieces are defined and then compounded together as needed to create more complex structures that can then be included in even more complex structures, and so on. All in all, it’s very similar to the method in which a house would be built: The wood is acquired and cut to the lengths needed, then the frame is built, and so on.

Again, though, if you take a closer look, you’ll see many important differences between the W3C schema and the DCD schema. For instance, as with the XDR schema, every element must have a separate type definition somewhere in the document. That means every time you wish to use an element, you must separately define its type definition and then declare that element where it will actually be used.