Re: ISSUE-41/ACTION-97 decentralized-extensibility

Shelley Powers wrote:
> On Mon, Oct 19, 2009 at 7:18 AM, Anne van Kesteren <annevk@opera.com> wrote:
>> Designing for the unknown future sounds like a waste of time and effort to
>> me. I forward compatibility is important, but adding a ton of complexity for
>> a need that may emerge in the future seems unsound.
>>
> 
> I read Tony's proposal. I didn't see a ton of complexity, especially
> considering that namespaces are already supported in the XHTML
> serialization of HTML5.

A lot of hidden complexity is in the parser processing rules, which 
Microsoft's high-level proposal doesn't go into.

For example, the spec would need to define the conformance requirements 
and expected namespaceURI/localName values in the following examples:

     <html xmlns:foo="test"> <foo:bar>

     <html xmlns:foo> <foo:bar>

     <html xmlns:0="test"> <0:foo>

     <html xmlns:="test"> <:foo>

     <html xmlns:foo="test"> <div xmlns:foo=""> <foo:bar>

     <html> <script>document.documentElement.setAttribute('xmlns:foo', 
'test')</script> <foo:bar>

     <html> 
<script>document.documentElement.setAttributeNS('http://www.w3.org/2000/xmlns/', 
'foo', 'test')</script> <foo:bar>

     <html> <foo:bar> <html xmlns:foo="test"> <foo:bar>

     <html xmlns:foo="http://www.w3.org/2000/xmlns/" foo:bar="test"> 
<bar:baz>

     <html xmlns:foo="test1"> <table xmlns:foo="test2"> <foo:bar>

     <html xmlns:xml="test"> <xml:foo>

     <html xmlns:xmlns="test"> <xmlns:foo>

     <html xmlns:xml="http://www.w3.org/XML/1998/namespace"> <xml:foo>

     <html xmlns:xmlns="http://www.w3.org/2000/xmlns/"> <xmlns:foo>

     <html> <xml:foo>

     <html> <xmlns:foo>

Implementors (of HTML5 parsers, and of other tools like RDFa processors 
that try to extract namespace prefix information) would have to deal 
with all these cases and match the spec's requirements, and authors 
would be exposed to some of the complexities when they write slightly 
unusual markup like this.

They're not insurmountable problems, but they are problems that wouldn't 
exist if a simpler syntax with fewer special cases and/or without prefix 
indirection was used.

Authors would also be faced with the complexity that "Namespaces" in 
text/html will have easily-encountered differences to how they work in 
XML - e.g. in Microsoft's proposal, default namespace declarations are 
either not supported or are not supported on <html> elements. Anyone who 
reads documentation or tutorials on Namespaces in XML will be misled as 
to how they work in HTML; they will instead have to learn the new 
HTML-compatible subset.

(Experience with XHTML suggests people aren't good at sticking to 
compatible subsets - e.g. they write <script src="..." /> in text/html 
and expect it to be parsed as an empty element, because that's how they 
were taught XML works, and they don't recognise the problems it causes 
in HTML.)

Developers of script libraries will also have to deal with three very 
different ways that element names with colons are parsed (the new 
behaviour, legacy Firefox/Safari/Opera/etc behaviour, legacy IE 
behaviour (presumably preserved indefinitely in compatibility modes)).

I think any proposal that encourages the use of colons in names 
introduces a significant amount of complexity along these lines.

(Complexity might be worthwhile if the benefits are sufficient, and if 
the benefits can't be achieved with less complexity through other 
solutions; but I don't believe that is the case here.)

-- 
Philip Taylor
pjt47@cam.ac.uk

Received on Monday, 19 October 2009 13:29:02 UTC