On Nov 17, 2009, at 7:58 PM, Karl Dubost wrote: > > Le 17 nov. 2009 à 13:56, Liam Quin a écrit : >> If a document is not well-formed, the XML specification >> does not apply to it - it's not XML. >> >> If a Web browser makes an XML DOM, however, it must find >> a way to mark the DOM so that an application (and the >> browser internals) can tell the input wasn't XML. > > > indeed that was one of my points in the past. > http://bit.ly/brokenxml > > it could be something like > xml:check="recovered" Who would be the client for knowledge that the document was not well- formed XML? Is this data expected to be consumed by the browser, or by client-side Web application scripts, or by something else? What are the use cases for the info? I ask because the target audience and use cases may suggest different ways of exposing the data. For a client-side script, the most convenient way would be a new IDL attribute on the Document interface. For purely browser-internal use, I believe there is no need to specify anything. FWIW, whether a parse error occurred is not exposed to Web pages at all for HTML, and as far as I know neither Apple nor the WebKit project have received any requests to expose it. Some information about parse-time behavior is exposed to the Web developer tools built into the browser, however, for debugging purposes. Regards, Maciej
Received on Wednesday, 18 November 2009 04:23:19 UTC