Re: Intent of ER-XML

On 27/02/2012 21:33, Noah Mendelsohn wrote:

> David Carlisle wrote:
>
>> the point is to have a well-defined common understanding of what
>> an element, attribute, etc. are. The fact that it maps onto
>> something that one can immediately implement is, I find, very
>> helpful in making it concrete.
>

actually that was Robin, but no matter.

> Well, at the very least, it's certainly helpful to the many
> implementors who will in fact be using the DOM.
>
> Maybe we're all not that as far apart in our positions overall as the
> tone of this thread might suggest? It's the "spec for a drop in
> replacement processor" goal that would make me nervous. Thanks.
>
> Noah

I'd like a processor conforming to an xml-er spec (aka an xml-er parser)
to be something that you can "drop in" substituting for a processor
conforming to the xml 1.x spec 9aka an xml parser).
that doesn't mean that the xml-er spec has to specify much or anything
about such a processor, on the contrary it means specifying things to
more or less the same degree as XML, which is hardly anything at all
about processing API.

this works _already_ but isn't that well standardised. I can take
Henri's validator.nu HTML5 parser, tell (say) saxon that it is a sax
parser and html5 goes in and gets processed by xslt as if it were xml.
It should be possible to "drop in" an xml-er parser in the same way at
the front of an xml pipeline and have the tree processed as if it were
xml. the last thing you want in order for that to happen is that the
processing API for xml-er be specified, it needs to be exactly as open
as it is for xml, so can use sax or xom or dom as the need arises.

David

Received on Monday, 27 February 2012 23:24:59 UTC