W3C home > Mailing lists > Public > public-html@w3.org > November 2009

Re: Automatic XML namespaces

From: Henri Sivonen <hsivonen@iki.fi>
Date: Fri, 6 Nov 2009 11:49:20 +0200
Cc: Liam Quin <liam@w3.org>, HTML WG <public-html@w3.org>
Message-Id: <3500D3CF-2E58-4CE2-AD02-770B7BDF9A94@iki.fi>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
On Nov 5, 2009, at 23:10, Aryeh Gregor wrote:

> On Thu, Nov 5, 2009 at 2:26 PM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> How would this differ from what HTML5 specifies now?
> My impression is that for browsers, it would not differ.  They would
> use a hardcoded list of namespace mappings and treat unknown elements
> just as they do now.
> In particular, I'm assuming that an ns.xml would be optional for all
> users of automatic namespaces

Making the semantics of the parser output depend on an optional  
feature is an incredibly bad idea.

There already is a case study about this in the context of XML:  
Optional DTDs when DTD processing involves infoset augmentation. The  
recent entity thread shows how DTDs are a big FAIL.

Authors can't use optional features reliably but implementors end up  
bearing the cost of having the optional features complicating the code  
base anyway. Optional features near enough the core of the system a  
lose-lose proposition. (Because, in a large project, it's really hard  
to maintain a policy that no one gets to commit patches that implement  
optional features of a standard, there's always a risk that someone  
commits an implementation of an optional feature and then you can't  
get rid of it. Or even if you have a no optional features policy, your  
competitor may be fooled into implementing an optional feature, so you  
do too. But authors can't reliably use it even then, because there's  
always another piece of software that doesn't support the feature.)

Henri Sivonen
Received on Friday, 6 November 2009 09:49:57 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:53 UTC