Re: [xml-dev] How to represent mixed content in JSON and JSONSchema?

["Liam R. E. Quin" <liam@fromoldbooks.org>]

On Sat, 2018-07-14 at 00:29 +0100, Norman Gray wrote:
> Ah no, you're not getting away that easily.  That specifies that
> order is constrained _in the source document_, but it is
> magisterially silent 
> on the order in which those elements are presented to the processing 
> application. 

The text file with the pointy brackets in it does not contain elements.
Instead, it contains start tags and end tags, character data, and so
forth. So what's presented is more often an event stream from which an
application constructs a representation of elements...

Once parsed, the _logical_ structure of a start tag, stuff, a matching
end tag, is an element.

All that matters is that they end up with their "children" property as
an ordered list -- see
https://www.w3.org/TR/2004/REC-xml-infoset-20040204/#infoitem.element -
[children] An ordered list of child information items, in document
order.

But it's indeed not forbidden to treat children as unordered if that's
appropriate for an application. In Perl i think XML::Twig might have an
option to do that, and at times it's useful.

Of course, we have to define what we mean by "order".  The XML
Information Set specification uses "document order" and so do XPath and
XDM, but that presupposes a 1:1 sequential mapping from the start-tag
stuff end-tag sequence to a document. In fact, as the XDM says,

[Definition: A document order is defined among all the nodes accessible
during a given query or transformation. Document order is a total
ordering, although the relative order of some nodes is implementation-
dependent. Informally, document order is the order in which nodes
appear in the XML serialization of a document.]
https://www.w3.org/TR/xpath-datamodel-31/#document-order

Of course, a parser could present the event stream to an application in
any _temporal_ order, including backwards (i've written a partial
backwards XML parser in C as it happens, but it constructs forwards
fragments).

> I think that the 'problem' here is that the XML spec is almost
> entirely 
> concerned with the syntax of the source document, and says
> remarkably 
> little about its semantics.

A large part of that is a _good_ thing.  Neither DOM nor XDM are the
only data models one can use to represent a parsed XML document.

You can run XML Query over relational data that's neither ordered nor
even stable, as long as it can in a single transaction meet the
requirements of the XDM.

So, XML leaves out a lot, and some of it is supplied by other specs
(such as infoset) and some of it is deliberately omitted, and some of
it was omitted by oversight.  I don't think XML::Twig was wrong to
offer unordered sequences of children (using a hash) as an option.
There's also XML::Config that _only_ offers that, but it's for reading
simple config files and nothing else.

Liam


-- 
Liam Quin, W3C until end of July
http://www.fromoldbooks.org/ https://www.holoweb.net/liam/cv/
Available for XML/Document/Information Architecture/
XSLT/XQuery/Web/Text Processing work and consulting.