Re: Subset Data Model

On 14/08/2012 00:08, Uche Ogbuji wrote:
> David, I don't think reductio ad absurdum works here, as John
> indicated before.
>
> To follow the example you suggest, XML 1.0 did not even specify the
> order in which elements should be reported by a parser.

Yes and that was a bad thing. The spec is short but it is only really
understandable (or you might say consistently implementable) if you
assume rather a lot of inherited SGML folk law about how things are
supposed to work. That is not a good precedent to follow.


> the XSLT 1.0 model could have said that node sets from a node match
> appear in alphabetical order of string value, rather than document
> order.  This would not have violated the syntax of XML 1.0, but it
> would have been absurd. It would have made it nearly impossible to
> do anything useful in that processing.
>
> So the XSLT/XPath 1.0 data model did what was sensible and useful
> (for the most part).  The MicroXML data model shall do the same.  I
> have heard nothing whatsoever to suggest otherwise, which is
> precisely why this reductio is merely tedious.

It's not tedious if someone asks a simple question asking if the
processing and/or data model will be compatible and they get strong push
back that _only_ syntax compatibility is guaranteed. That gives a (real)
impression that processing compatibility is _not guaranteed.


>
> What we *have* said is that we will not define what is sensible and
> useful by strict derivation from any present data model spec.  Of
> course a difference in behavior between MicroXML and Infoset, and
> heck, maybe even XDM could count as an argument against any
> particular choice. Our point is simply that it's an argument that
> has to be made.  That will be facilitated, once again, once we
> actually have a straw man MicroXML data model to throw darts at.

Given the loose way in which various data models are tied to the XML
syntax I actually suspect it would be rather hard to formally specify
how any micro-xml data model relates to XML. You wouldn't want to assume
DOM processing for example and specify everything in terms of DOM (even
though that would help with other aims of HTML5 interaction)

However I do think that any eventual spec should make it clear (in
words) that any tree building or event reporting parse of micro-xml
should be expected to be compatible with the tree or parsing events
produced by an xml parser on the same source.

In either English or Latin you and John have said that it would be 
_absurd_ to suggest that any other behaviour is possible.

So given that html5 compatibility is another possible motivating factor 
of micro-xml and that

<math><mfrac><img src="a"/><img src="b"/></mfrac>

parses as both xml and html  and presumably parses as micro-xml as well
is it really absurd to ask that the micro-xml parse not only reports 
that the file is well formed but that it reports the same tree as xml 
not the tree that the html parser reports, which is

<math><mfrac/></math><IMG src="a"/><IMG src="b"/>

This is not an "absurd" example it is the way a current specification 
specifies that this syntax be parsed.

http://livedom.validator.nu/?%3C!DOCTYPE%20html%3E%0A%3Chead%3E%3Ctitle%3E%3C%2Ftitle%3E%3Cbody%3E%3Cmath%3E%3Cmfrac%3E%3Cimg%20src%3D%22a%22%2F%3E%3Cimg%20src%3D%22b%22%2F%3E%3C%2Fmfrac%3E%3C%2Fmath%3E%0A

David


-- 
google plus: https:/profiles.google.com/d.p.carlisle

Received on Monday, 13 August 2012 23:35:11 UTC