[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: John Cowan [mailto:jcowan@reutershealth.com]
> Sent: Tuesday, January 21, 2003 10:29
> To: Eric van der Vlist
> Cc: Jeff Lowery; 'Bryce K. Nielsen'; 'xml-dev'
> Subject: Re: [xml-dev] Can XML Schemas do this?
>
>
> Eric van der Vlist scripsit:
>
> > Together with confusing the usage of elements and
> attributes, another
> > bad habit taken during our few years of XML experience is the
> > assumption that schemas should always enforce a fixed order between
> > children elements or in other words that relative order between sub
> > elements always matters.
>
> I think this conflates two issues. It's analogous to the bilingualism
> paradox: in countries where most people are monolingual (but
> not all speaking the same language), it is common for the
> government to be officially bilingual (e.g. Belgium, Canada);
> in countries where most people are bilingual or multilingual,
> it is common for the government to be monolingual (e.g. most
> African countries).
>
> Similarly, if the order of child elements is meaningful, then
> the schema should allow the children to appear in any order;
> if the order is not meaningful, then there is no reason to
> allow multiple orders (other than backward compatibility).
> If multiple orders are allowed nonetheless, people may easily
> come to believe that order has significance and use it as if it did.
I absolutely agree. In the last few weeks, I have been looking for a
good example. Here is one I came up with just this morning.
When you list the people who contributed to a book, or a standard, etc.,
you often put the names in alfabetical order. The reason is simple:
you don't want to imply any kind of ranking or precedence between
different people. The fixed alphabetical order used in this case is a
"human" protocol that the editor uses and the readers understand.
If the alphabetical order is not used, readers can infer any sort of
"ranking" information from the order: Who contributed more and who
contributed less; who is older and who is younger; who joined first and
who joined later; who is more known and who is less known; and so on.
The fixed alphabetical order - as per the implicit "human" protocol
mentioned above - in this case is helpful in that it positively avoids
conveying to the reader extra information that was not intended by the
"sender".
A different example: I want to list the people that were sitting
together at the table at dinner. I may want to start from a pre-agreed
seat and go clockwise or anti-clockwise, this also pre-agreed. Using
the order in the message to represent some "order" in the real world is,
in this case, a natural and straightforward solution.
Note that in the second example, I need to allow arbitrary order in the
message, but I am attributing some semantics to the order. Whereas in
the first example, I want to *avoid* associating any semantics with the
order, therefore I am forbidding arbitrary order (by mandating
alphabetical order).
If the order is regarded as a constraint that the schema imposes on the
documents, then the existence of the constraint can be described as
"less entropy" in the message and the absence of the constraint can be
described as "more entropy" in the message.
A possible question is, Why do we want to put "more entropy" in the
message if we are not interested in the extra "information" that
corresponds to the increased entropy? (Or worse, when the extra
"information" is completely undefined and the readers can infer just
anything?)
Alessandro Triglia
>
> > [W]e shouldn't bother users and applications with the unecessary
> > constraint of enforcing [ordering].
>
> But that shifts the burden from validation to processing. If
> we don't enforce order at validation time, then we must have
> a more general processing loop that can accept any element at
> any time. If we do enforce order, then the processing stage
> can be simpler: accept a "foo" if there is one, accept a
> "bar", accept a "baz", etc. etc. In streaming applications,
> a well-chosen order of children (viz. no forward references)
> can make processing much more straightforward.
>
> > With Relax NG, defining content models where the relative order
> > between children elements is not significant is not only almost as
> > simple as defining content models where it is significant
> (it's just a
> > matter of adding "interleave" elements) but it is also more
> extensible
> > since these content models can easily be extended through pattern
> > combinations by "interleave".
>
> "It can be done" is no argument for "it should be done".
>
> --
> "No, John. I want formats that are actually John Cowan
> useful, rather than over-featured megaliths that
http://www.ccil.org/~cowan
address all questions by piling on ridiculous
http://www.reutershealth.com
internal links in forms which are hideously
jcowan@reutershealth.com
over-complex." --Simon St. Laurent on xml-dev
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
