- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Sun, 26 Feb 2012 13:52:31 -0500
- To: David Lee <David.Lee@marklogic.com>
- CC: "public-xml-er@w3.org" <public-xml-er@w3.org>
On 2/26/2012 11:16 AM, David Lee wrote: > B) Wrong Question XML-ER specs do not define a 'Processor' > > 3) XML-ER does not define an implementation of anything. Rather it defines > a set of rules for fixing up XML. This is pretty much my answer, though I'd prefer to say something like "it's a set of rules for mapping an input document to an output tree, with the following specific requirements: * If the input is well formed XML+Namespaces, then the output must be the corresponding {Infoset, XPath, Tree form TBD} * If the input is not well formed, but meets certain other characteristics (TBD) suggesting that it nonetheless is trying to encode a tree using XML-like TAGs, then a) produce a tree that with reasonable likelihood captures the tree intended by the author b) facilitate identification of subtrees that resulted from input subtrees that were not well formed (I.e. identify subtrees for which "fixup" was done). * MAYBE: if the input bears no relationship to XML markup, e.g. appears to be binary, contains no TAGs at all, begins with the characters />, whatever, then we can decide whether it's best to define a mapping to a tree anyway, or to just rules such input out of the domain of the mapping function. Either way, I strongly feel that we should focus on the mapping, and not the processor or its API. Noah
Received on Sunday, 26 February 2012 18:52:56 UTC