W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > November 2009

Re: XML namespaces on the Web

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 17 Nov 2009 20:22:43 -0800
Cc: Liam Quin <liam@w3.org>, Boris Zbarsky <bzbarsky@MIT.EDU>, John Cowan <cowan@ccil.org>, public-html@w3.org, public-xml-core-wg@w3.org
Message-id: <96F99ECE-8533-440B-9E47-4624A618FE51@apple.com>
To: Karl Dubost <karl+w3c@la-grange.net>

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:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:41 UTC