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

Re: Charter

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Wed, 15 Feb 2012 19:32:47 -0500
Message-ID: <4F3C4EAF.1060304@arcanedomain.com>
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.

Received on Thursday, 16 February 2012 00:33:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:47:26 UTC