- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Wed, 15 Feb 2012 19:32:47 -0500
- To: Shane McCarron <shane@aptest.com>
- CC: public-xml-er@w3.org
On 2/15/2012 3:04 PM, Shane McCarron wrote: > I concur. > > On 2/15/2012 2:01 PM, Robin Berjon wrote: >> On Feb 15, 2012, at 20:57 , Norman Walsh wrote: >>> How about if we soften it a bit: >>> >>> Applications that perform error recovery should provide a mechanism >>> for identifying when recovery was performed on a document. >> Ah yes that works for me; I think that error reporting (to developers) is >> very important when recovery happens. >> I'm a little nervous about mixing a specification for a tree mapping with a specification for a processor with a specification for an API. I would be happy if this group: * Produced specification for a mapping from (potentially poorly formed/erroneous) XML to a tree. Presumably, in the case where the XML is well formed, the tree should match or at least be close in spirit to the infoset (or XPath data model or DOM or whatever we think is the right point of reference.) * Demonstratated that implementations of the mapping are practical, and that it's possible to do streaming implementations. I suspect it's trivially true of most any mapping we would promote, but we should also show that it's >possible< for those who wish to to build APIs and/or applications that distinguish cases in which the input was well formed from cases where it wasn't. I don't think we should say anything about what a processor is, what a conforming processor is, or what APIs are preferred. People should design the APIs they need, with as much or as little error reporting as appropriate to the situation. Some APIs may wish to report not only that there were errors, but also to identify the parts of the tree in which they occurred. Others may wish to report a single (error/no-error) bit, or there may be situations in which no such reporting is needed. Noah
Received on Thursday, 16 February 2012 00:33:14 UTC