W3C home > Mailing lists > Public > public-xml-er@w3.org > February 2012

Re: Intent of ER-XML

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Mon, 27 Feb 2012 10:25:54 -0500
Message-ID: <4F4BA082.50307@arcanedomain.com>
To: Robin Berjon <robin@berjon.com>
CC: David Lee <David.Lee@marklogic.com>, "public-xml-er@w3.org" <public-xml-er@w3.org>


On 2/27/2012 9:56 AM, Robin Berjon wrote:
> It's very much possible that I'm being dumb and missing an important
> distinction here but I'm having a hard time figuring out how we could
> define a mapping from an input document to an output tree that would be
> all of interoperable, usable, and not a processor. Can someone please
> illuminate me?

As one who's been advocating the "output tree" approach, I think what 
you're missing is the proposed layering of the specifications. The XML-ER 
specification would be a shared building block on which multiple different 
sorts of processors could be specified, as is the case with the XML 
Recommendation today. An interoperable specification of a processor seems 
to require documentation of the input and output API, since that's the 
level at which software typically "interoperates".

What I'm proposing is a layering of the specifications. In particular, 
XML-ER would stay pretty near the level of the XML Recommendation, 
preferably leaving out the bits that do talk about processors. The XML 
recommendation tells you things like which sorts of input correspond to 
elements, which to attributes, which to attribute values, etc.

Just as with XML itself, with that in hand, additional specifications are 
then written to achieve interoperation of processors. So, we can have 
specifications for SAX, DOM, JAXP, .Net System.XML or whatever. Each of 
these is a specification for an interoperable set of processors, and all 
defer to the base XML-ER specification for the mapping from input forms to 
(abstract) elements, attributes, etc. Each will have its own notions of how 
(if at all) to reflect warnings, etc. In short, I want to be able to share 
the core definition of XML-ER across the specifications for all the 
different sorts of processors.

BTW: though I've advocated an abstract output tree in this thread, I did 
early mention the attractions of defining a mapping from non-well formed 
input character streams to well formed output character streams. As I said 
before, this would allow us to directly leverage all the existing 
specifications and code that operate on well-formed XML. It's also clear 
how conformance testing could be achieved in an interoperable way. Of 
course, I don't assume that typical implementations would necessarily 
reserialize the well-formed XML, but it might be the right level at which 
to right an XML-ER specification.

Noah
Received on Monday, 27 February 2012 15:26:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 February 2012 15:26:23 GMT