Web Development
by builder
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!).
by j henderson
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 tag.
Take the following example:
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:
by grantwparks
by tim.bills
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.
by j henderson
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.
by builder
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
by builder
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):
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
This discussion is closed to new replies.
Sort by Trending