[
Lists Home |
Date Index |
Thread Index
]
- From: Ronald Bourret <rpbourret@rpbourret.com>
- To: Eric van der Vlist <vdv@dyomedea.com>
- Date: Fri, 20 Oct 2000 11:44:37 -0700
Eric van der Vlist wrote:
> 1) Should we always pay attention to the relative order of the elements
> within XML documents ?
First, I think it is important here to clarify that there are three
types of order in an XML document: hierarchical order, sibling order,
and document order.
Hierarchical order determines who is the parent and who is the child. I
cannot think of any reasonable cases for which hierarchical order is not
important.
Sibling order is the order in which siblings (elements/text with the
same parent) appear in that parent. To me, this discussion is about
sibling order, so more about that in a moment.
Document order is the order in which elements/text appear in the
document. This is important in some cases (such as XSLT), unimportant in
others. Note that document order can be determined from hierarchical and
sibling order, and that if you preserve hierarchical and sibling order
you preserve document order.
So the question is, is sibling order always important. The answer is,
absolutely not. Here's the two cases:
In general, sibling order is always important in document-centric
applications. For example, I like the first review but not the second:
<Review>
<p>Ronald Bourret is an
<b>excellent writer</b>.
Only an <b>idiot</b>
wouldn't read his work.</p>
</Review>
<Review>
<p>Ronald Bourret is an
<b>idiot</b>. Only an
<b>execellent writer</b>
wouldn't read his work.</p>
</Review>
On the other hand, sibling order is often unimportant in data-centric
applications. For example, both of these XML documents:
<Part>
<Number>123</Number>
<Desc>Turkey wrench</Desc>
<Price>10.95</Price>
</Part>
<Part>
<Price>10.95</Price>
<Desc>Turkey wrench</Desc>
<Number>123</Number>
</Part>
map to the following object:
object part {
number = 123
desc = "Turkey wrench"
price = 10.95
}
The reason for this is that objects have no notion of order among their
properties.
This is not to say that order is never important in data-centric
applications. For example, if you ship an XML document containing part
information and sales orders to an application that stores the data in a
database, the part information needs to appear before the sales orders.
The reason for this is that the sales order reference part numbers and,
if you try to add the sales orders to the database before the part
numbers, you will hit referential integrity errors.
However, there is a large class of tools emerging to use XML as a way to
serialize Java objects and that view XML documents as trees of objects
and store them accordingly in databases. For these tools, sibling order
simply is not important. Personally, I suspect that these tools are
going to be the foundation of data-centric XML applications in the
future, with XML used only as a data transport. Examples of these tools
are Castor, all XML-enabled relational databases (Oracle, SQL Server,
DB2, Informix), and XML servers such as Bluestone and eXcelon.
I haven't looked closely enough at Bluestone and eXcelon, but, from what
I can tell, of Castor and the relational databases, only DB2 (and even
then I'm not sure) appears to be able to store sibling order information
in the database. This means that these products simply don't consider
sibling order to be important.
Note that the question that started this entire thread on the XML schema
list -- the ability to specify occurrence values in an all group -- is
definitely applicable here. This is because objects (whether Java
objects or data stored in an object-relational database) can have a
mixture of single and array-valued properties, so serializations of
these objects will have all groups in which occurrence values are
important.
I have no idea about how difficult this is to implement, but I would say
that the response from Michael Sperberg-McQueen:
> I have no trouble imagining users who say that
> is what they want; I am having trouble imagining a case where they
> are right.
flies in the face of all current relational database implementations of
XML.
--
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com
|