On Wed, 7 Mar 2001, Ralph Hartley wrote:
> [...]
> >> I don't like this, but I don't know that it violates any of my
> >> principles. The XML spec says nothing about the importance of ordering
> >> between elements of the same type.
> >
> > Excuse me?
> >
> > Any XML tool that shuffled the order of elements would distroy
> > documents. Paragraph elements can't be reordered, as an example.
> > It is not hard to come up with other examples.
>
> This is true. But what I said about the XML spec is true too. In fact it
> does not appear discuss the MEANING, or possible transformations, of a
> document at all (Please do correct me if either of these statements is
> wrong, I could have missed something).
It doesn't discuss the meanings. (Nor should it.)
But I sure can't find anything in the standard that allows any
parser to hand elements to an application in order different
than given. (Order is preserved in the DOM, and it is preserved
in SAX parsers.)
The standards that depend on XML (such as Xpointer and XSL) depend
on the file being presented in order.
There are statments about order all over relevant standards.
I'm significantly confused as to where you find in the standard
any license to change the order. What tool have you seen that
doesn't preserve order?
What "possible transformations" are you talking about?
(The XML standard talks about the format of a file, not about
what you want to do with it... I'm not sure I see why you
would expect it to talk about transformations of the file
to begin with, much less allow any.)
I may be wrong, but I believe this issue was beaten to death
back in the "No XML, only SGML" days, and XML has just
inherited the SGML view of documents. (XML is, after all,
a subset of SGML.)
> Of course many actual document types do depend on the ordering for their
> correct interpretation, so it must be safe to assume that general XML
> tools will preserve it.
This is correct.
> >> We could define it to be significant,
> >> ... I would prefer to define CaveXML so that the order is NOT
> >> considered meaningful, only the nesting structure is.
> >
> > Well, that wrecks any documentation I put in.
>
> Let me amend that to "The order of SOME elements is not significant".
The oder is always significant. Period.
If you want to say that an output file can have some specific CaveXML
sections reordered, fine. But that's much different than saying that
that the order in the file is not significant.
Maybe you are just using different terminology than I am.
Are you a user of XML parsers?
> Any documentation that was nested within elements that were reordered
> would, of course, be dragged along.
> Remember that some programs require shots in a PARTICULAR order, and
> they may not all accept the same order. A CaveXML->other->CaveXML round
> trip, done in the simplest way, would not be expected to preserve the
> order of the shots. If there were no reordering freedom at all, the
> round trip would be considered to make a significant change.
My Personal opinion: (If you dissagree, send me private mail and
you can later post a summary so that everyone doesn't have to sit
through the discussion.)
If a given program needs a table of shots in some order, it should
make itself such a table, and leave what's already there alone.
> Be that as it may, I think I could accept enough significance in the
> ordering of stations and shots for the above fragment to have the
> obvious interpretation.
If you reorder shots, I can no longer reconstruct the original data
order from them. Which is part of the reason that I'd prefer to
have each pass thorugh the file of anything I write just add things,
or change things it has written itself.
> [...]
This archive was generated by hypermail 2b30 : Mon Apr 02 2001 - 18:00:00 CEST