General discussion

Locked

Debate between DTDs and schemas

By Mark W. Kaelin Editor ·
Do you prefer using DTDs, or are you sold on schemas? Tell us what you think about the debate between DTDs and schemas.

This conversation is currently closed to new comments.

8 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Comments

Collapse -

Schemas

by Ed Woychowsky In reply to Debate between DTDs and s ...

I like schemas, but it may be because I?m a big fan of XSLT.

Collapse -

Schema discards an OO advantage of DTD

by builder In reply to Schemas

The one "con" listed for schemas is irrelevant.
Which one came first doesn't much matter.

I would probably favor schemas for anything
non-trivial, except for one major brain-fade:
You can't specify (so far as I can tell) that the
order ofappearance of tags doesn't
matter--which is one of the major
simplifications of XML.

In XML Schemas, an ADDRESS might have
the fields LINE1, LINE2, CITY, STATE, and ZIP,
with exactly one of each tag required except for
LINE2, which is optional. This would have to
be declared as a sequence, which indicates a
required order. It could be declared as an ANY
array, but then you lose the containment
restrictions.

But the *order* of the tags is irrelevant. They
are attributesof an object. Period.

A DTD doesn't enforce any sequential
ordering whatsoever--just the number and
type of elements that may be contained in a
given element.

So, unfortunately, since XML Schema is
virtually required for web services, we are left
with the twisted approach of first specifying a
required order of contained elements (using
'sequence'), then turning around and ignoring
that order when it doesn't really matter (which
is almost all the time!).

Collapse -

Re: Schema discards an OO advantage ...

XML Schema is not as "twisted" as you might think...

If I understand your issues, I believe your concerns about schema are incorrect.

To accomplish what you are suggesting, you should use the <all> tag.

Take the following example:

<xsd:element name="person">
<xsd:complexType>
<xsd:all minOccurs="0">
<xsd:element name="line1" type="xsd:string"/>
<xsd:element name="line2" type="xsd:string"/>
</xsd:all>
</xsd:complexType>
</xsd:element>


This example indicates that "line1" and "line2" can appear in any order, and each element can appear at most once.

So it is possible to have an element that contains elements that appear in any order.


With respect to your second issue, you can create an address element with an optional line 2 as follows:


<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="address" type="AddressType"/>
<xsd:complexType name="AddressType">
<xsd:sequence>
<xsd:element name="line1" type="xsd:string"/>
<xsd:element name="line2" type="xsd:string" minOccurs="0"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="state" type="StateType"/>
<xsd:element name="zip" type="ZIPCodeType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="StateType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="[A-Z]{2}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ZIPCodeType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="[0-9]{5}(-[0-9]{4})?"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

Collapse -

Aha! xds:all

by builder In reply to Re: Schema discards an OO ...

0. I apologize for not replying earlier; I gave up on the thread after several weeks of no posts.

1. I'm aware of minOccurs='0' for making an element optional.

2. I was not aware of xsd:all; I had searched thoroughly for a modifier attribute on xsd:sequence that made it ignore order. What can I say--XML schema is complicated.

That said, other than the perceived inability to describe order-independent elements in a complex type declaration--which is handled by xsd:all--I tend to prefer XML schema over DTDs. XML schema is verbose, and the verbosity can make it difficult to read, but it provides a much more complete and precise description of what should be in an XML document.

FWIW, I *think* the address declaration to express an address object would look like this (adapted from the previous message and indented for readability):

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="address" type="AddressType"/>
<xsd:complexType name="AddressType">
<xsd:sequence>
<xsd:all>
<xsd:element name="line1" type="xsd:string"/>
<xsd:element name="line2" type="xsd:string" minOccurs="0"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="state" type="StateType"/>
<xsd:element name="zip" type="ZIPCodeType"/>
</xsd:all>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="StateType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="[A-Z]{2}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ZIPCodeType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="[0-9]{5}(-[0-9]{4})?"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

In other words, an address consists of exactly one instance of each of the elements line1, city, state, and zip, and may contain zero or one instance of the element line2. (This is a simplified, if common, encoding of an address; it suffices to show what I expect from a structure/data type that represents an object with unordered data elements.)

Thanks for the nice StateType and ZIPCodeType examples, as well.

FWIW, I fail to understand why the default behavior is to force ordering, but I can live with it. I'll just use xsd:all in almost all cases.

- Sam

Collapse -

Aha! xsd:all (repost)

by builder In reply to Re: Schema discards an OO ...

0. I apologize for not replying earlier; I gave up on the thread after several weeks of no posts.

1. I'm aware of minOccurs='0' for making an element optional.

2. I was not aware of xsd:all; I had searched thoroughly for a modifier attribute on xsd:sequence that made it ignore order. What can I say--XML schema is complicated.

That said, other than the perceived inability to describe order-independent elements in a complex type declaration--which is handled by xsd:all--I tend to prefer XML schema over DTDs. XML schema is verbose, and the verbosity can make it difficult to read, but it provides a much more complete and precise description of what should be in an XML document.

FWIW, I *think* the address declaration to express an address object would look like this (adapted from the previous message):

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="address" type="AddressType"/>
<xsd:complexType name="AddressType">
<xsd:sequence>
<xsd:all>
<xsd:element name="line1" type="xsd:string"/>
<xsd:element name="line2" type="xsd:string" minOccurs="0"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="state" type="StateType"/>
<xsd:element name="zip" type="ZIPCodeType"/>
</xsd:all>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="StateType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="[A-Z]{2}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ZIPCodeType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="[0-9]{5}(-[0-9]{4})?"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

In other words, an address consists of exactly one instance of each of the elements line1, city, state, and zip, and may contain zero or one instance of the element line2. (This is a simplified, if common, encoding of an address; it suffices to show what I expect from a structure/data type that represents an object with unordered data elements.)

Thanks for the nice StateType and ZIPCodeType examples, as well.

FWIW, I fail to understand why the default behavior is to force ordering, but I can live with it. I'll just use xsd:all in almost all cases.

- Sam

Collapse -

Where's the logic?

by grantwparks In reply to Debate between DTDs and s ...

How can schema's con be "timing"? That's like saying the con to automobiles is their timing, after all horse-drawn carts were around for much longer. There is an endless supply of analogies I could draw here. It's just totally illogical to say that the one failing of a technology is that it's newer. Shame!

Collapse -

Debate between DTDs and schemas

by tim.bills In reply to Where's the logic?

My vote is for schema as well. The main reason is the data typing that I don't get through a DTD. However, if you're not going to take advantage of the data typing, DTDs are less verbose and therefore a little easier.

Actually, I'm a proponent ofschema backed up by Schematron to do the relationship validations that neither schema or dtd can do.

Collapse -

Schemas all the way!

I believe that we will see less and less DTD in the future as it is replaced by a more extensible mechanism to describe XML documents: Schemas.

Schemas provide primitive type mechanisms which can be validated (like positiveInteger). Schemas can also be used to created more complex, user-defined types which can ultimately be used by elements. (DTD do not provide much in the way of data typing.)

Given this control over typing and extensibility, it will allow developers to more easily map constructs from relational databases (especially where required data for an XML element may be from more than one table in the database). It also allows easier validation of data when if the database is updated.

The one thing to be wary of is vendor-specific extensions to schemas. If you're going to use schema, stick with the W3C Recommendation to provide maximum portability.

Back to Web Development Forum
8 total posts (Page 1 of 1)  

Related Discussions

Related Forums