[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: How to represent mixed content in JSON and JSONSchema?
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|