- From: David Carlisle <davidc@nag.co.uk>
- Date: Sun, 26 Feb 2012 22:34:28 +0000
- To: public-xml-er@w3.org
On 26/02/2012 22:21, Noah Mendelsohn wrote: > but fwiw my intuition is that the layering of the specifications > would be better if we first documented the mapping from input to > output, without describing in detail any particular piece of > software that might implement such a mapping. Maybe there is a terminology clash somewhere, as I would say that the current draft meets that description. (If you view DOM references with a sufficiently abstract way). It basically defines a mapping from an input string of unicode characters to an abstract tree representation. It doesn't (or need not) define any API to interact with that tree (although if the tree is described using the DOM there is an obvious mapping to the DOM API). What David Lee was (I think) asking for is something more, a mapping defined from an input string to the string representation of a document matching the productions in the XML 1.x spec that should work somehow without needing a full parser being specified (and, presumably run) on the input stream. I don't have any philosophical objection to such a system (I often edit xml without putting it through a full xml parse with Emacs lisp or perl or whatever) but in this case I can't imagine how it would work as any way I can imagine fixing up the result tree involves finding out what was wrong with the input tree by parsing it. David
Received on Sunday, 26 February 2012 22:34:49 UTC