OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Should we care about elements order ?

[ Lists Home | Date Index | Thread Index ]
  • From: Ronald Bourret <rpbourret@rpbourret.com>
  • To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
  • Date: Fri, 20 Oct 2000 13:42:59 -0700

Tim Bray wrote:
> 
> At 11:44 AM 20/10/00 -0700, Ronald Bourret wrote:
> >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.
> 
> I'm not convinced that document order and sibling order are different
> things.  Any XML instance has a root element, so all ordering issues are
> really sibling-ordering issues.  Or am I missing something?

Hmmm. You might be right. I brought it up because in the area I work in
(XML and databases), products generally preserve hierarchical order but
not sibling order. But when I try to think of an example in which the
sibling order is preserved but the hierarchical order isn't, I end up
changing the sibling order by adding an element as a sibling.

For example, consider the following document:

   <A>
      <B>
         <C>...</C>
         <D>...</D>
      </B>
   </A>

If you try to give it a different hierarchical order, such as the
following, you necessarily change the sibling order of the children of A
and B by removing C as a sibling of D and adding it as a sibling of B:

   <A>
      <B>
         <D>...</D>
      </B>
      <C>...</C>
   </A>

So while document order can be split into hierarchical order and sibling
order, the split isn't quite as clean as I thought.

(Note that in my previous email, I said I thought that hierarchical
order was always important. The documents above show an example of when
it might not be. This occurs when the structure introduced by B is
unimportant. That is, when C and D are really "properties" of A and B is
introduced for convenient, perhaps visual, grouping purposes.

A common example of this is when a Customer element contains an address
consisting of a street, city, country, and post code elements. If the
processing application views these elements as properties of the
customer, it doesn't matter whether they are directly under the Customer
element or grouped in an Address element -- the application will
eventually process them in the same way.)

-- 
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS