- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Mon, 27 Feb 2012 10:25:54 -0500
- 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 UTC