- From: David Carlisle <davidc@nag.co.uk>
- Date: Sun, 04 Mar 2012 20:06:18 +0000
- To: public-xml-er@w3.org
On 04/03/2012 18:44, Robin Berjon wrote: > as advantages that none of the alternatives have: > > • We already have a lot of the specification work done. > • It takes the "HTML at the front of an XML pipeline" case into account. > • It uses the DOM, which is the simplest and loosest model. > • It is more user(-agent)-friendly. > > In general it also seems (to me) a lot closer to the sort of things > that people in the HTML/XML TF or at XML Prague have indicated they > were interested in doing. > I agree that the web/dom usage should be the driving use case, however I'm not convinced that tweaking the tokenisation rules to ensure that the DOM constructed corresponds to well formed XML is a major burden to place on xml-er processors. If xml-er isn't just to be used for xhtml and is to position itself as a general purpose "xml recovery" parser specification, I think producing output usable by applications expecting xml parser output is an absolute requirement. I don't see why enforcing that the element names match the XML Name production impacts on _any_ of the advantages you list above. David
Received on Sunday, 4 March 2012 20:06:40 UTC