Re: error recovery

On 2/16/2012 7:54 PM, David Carlisle wrote:
>
> I think the most useful way to view the html parser (which is supposed to
> be a motivating example) is not that it does error recovery, just that the
> parse rules are more open than one might have expected, resulting in more
> (in fact in that case, essentially all) input strings resulting in a parse
> tree.

+1. As I said in my earlier note, I think it's fine to look for designs 
that can distinguish well formed input from other input, and maybe those 
that can do a good job of identifying the parts of the subtree 
corresponding to input that is not well formed (though, e.g. with 
namespaces, it may be ambiguous whether the fixup should be to correct an 
erroneous namespace declaration or markup referring to an undefined prefix, 
etc.).

Yes, there's a sense in which input that's not well formed is in error, but 
I think I'm OK de-emphasizing that in this context. It may be, eventually, 
that what looks like an error from the perspective of XML 1.0 might be 
viewed as correct for some applications of this technology. I don't see why 
we need to decide that now...just produce a mapping and move on.

Noah

Received on Friday, 17 February 2012 01:11:37 UTC