John Halleck wrote:
> 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.)
But I can't find anything in
http://www.xml.com/axml/testaxml.htm
that says that an XML processor must hand them over in any particular
order. Considering the density of that document, I could have missed
something, in which case please point it out.
Is that document not the whole XML spec? It doesn't mention the "DOM",
and the behavior of particular implementations (SAX parsers) is not part
of a standard unless the standard says so.
> The standards that depend on XML (such as Xpointer and XSL) depend
> on the file being presented in order.
Do they depend on an undocumented feature?
> There are statments about order all over relevant standards.
But none (on this point) in the XML standard, that I can find. I have to
admit to being a little perplexed.
> 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.)
Just so. There is more to a data format that it's syntax. The XML
standard doesn't talk about the semantics of a file at all. And that is
what I am talking about now. The XML spec DOES allow arbitrary
transformations, because "it places no constraints on the application"
(http://www.xml.com/axml/notes/AppIsFree.html).
The problem I am trying to grapple with here, is that in order to be
acceptable to sufficiently many users, CaveXML must allow the same data
to be expressed in different ways. There are so many combinations of
usages possible in even the simplest of our proposals, that it may be
difficult for a simple program to understand what a file is supposed to
mean (even though the file has been parsed already).
As well as a DTD or schema, we need an unambiguous description of what
each construct means.
One way to simplify this description would be to provide set of
transformations, and define the meaning of files that are related by
those transformations to be equivalent. In some cases it could also be
useful to define a "canonical" form (or forms), This would greatly
simplify the task of applications that need to read a CaveXML file,
because they would only need to understand one form.
It might also be useful to define more than one level of equivalence.
Some more stringent that others.
The loosest form of equivalence would be "basic". Two files would be
"basicequivalent" if they contain the same "basic" survey data (the same
shots), even if things like "groupings" were left out.
There might also be a "strict" equivalence, where it is defined that
"strictly" equivalent files have exactly the same meaning even it they
are not identical. Strict transformations would have to be reversible.
The most useful level of equivalence would be between these. It might
also be useful to define some transformations as "information adding",
(e.g. the meaning of a file with a certain element added in a certain
place is (defined to be) the same as that of the original except that
some information has been added).
This is still a bit loosely defined. I know XSLT is a standard for
defining transformations, but I don't know how it works, and have
negative time available to find out.
>> Let me amend that to "The order of SOME elements is not significant".
>
> The oder is always significant. Period.
Something is significant if we decide that it is. Significance is a
semantic term, as such it is not part of XML.
> Maybe you are just using different terminology than I am.
I must be.
>
>> 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.
I have already conceded that my principles require that if any
reordering is allowed, there must be a way to preserve enough
information to recover the original order.
Also, nothing I have said should be construed to imply that any of YOUR
applications need to apply any transformations to anything whatsoever.
Ralph Hartley
This archive was generated by hypermail 2b30 : Mon Apr 02 2001 - 18:00:01 CEST