Re: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

On Thu, 31 Jul 2008, Sam Ruby wrote:
> 
> Others seem to have come to a different conclusion:
> 
> http://lists.w3.org/Archives/Public/public-html/2007Sep/0501.html

The above e-mail, as well as the blog post to which it refers, both formed 
part of the great wealth of information that went into the design that 
currently exists in the HTML5 spec (partially commented out), as discussed 
in ridiculous amounts of detail last April:

   http://lists.w3.org/Archives/Public/public-html/2008Apr/0205.html

Regarding the specific points that that e-mail raises:

| 1. Allowing distributed extensibility using xml namespace like syntax.

The XML namespace syntax, specifically prefixes, is the source of huge 
amounts of author confusion, and on balance as far as I can tell adding 
this to HTML would be mistake. (Just consider Micah Dubinko's statement 
that 90% of the e-mail he gets about his XForms book is about the 
namespace syntax. 90%! And that's amongst early adopters and 
professionals, the most competent developers!)

The non-prefix parts of HTML, namely the xmlns="" attribute and default 
namespace declarations, can't be used as is without severe restrictions, 
due to the massive amounts of legacy content on the Web that abuses the 
xmlns="" attribute in all kinds of nonsensical ways.

In a severely restricted form, with the namespace dispatch mechanism based 
on tag names instead of the xmlns="" attribute value, an "xml namespace 
like syntax" is indeed used by the HTML5 proposal.


| 2. Robustness in handling unknown markup.

The HTML5 spec defines handling of all markup, known and unknown, and 
handles all foreign content (known or unknown) in a consistent manner, so 
this is covered.


| 3. Re-use of existing syntax and idioms for extensibility

There is nothing in the HTML5 foreign content proposal that introduces new 
syntax of any kind, it's all based on HTML and XML (and SGML) conventions.


| 4. A balance between simplicity of authoring and richness of
| functionality.

This is obviously a judgement call, but in my opinion we have reached a 
good balance: the foreign content parsing mode is easily added to an HTML5 
parser with little effort, supports any XML vocabulary with just one minor 
addition per vocabulary (the tag name to invoke it needs to be added to 
the list of ways of entering the foreign content mode), and it introduces 
all of MathML (and potentially SVG) into the Web platform under the 
text/html MIME type.


Note, by the way, that the TAG coming to the conclusion that your post 
introduces new information is not that surprising, given that the TAG also 
thinks that HTML5 introduces new information, even when all it is doing 
is describing the status quo. For example:

   http://www.w3.org/2008/07/24-tagmem-minutes.html#item03



Regarding the specific blog post that the e-mail cites:

The crux of the proposal is to use namespace prefixes. The blog post even 
explicitly apologises for this, saying that "[namespaces are] not 
necessarily well liked", but just puts forward this solution as the only 
valid solution. It's obviously not the only valid solution, since the 
HTML5 proposal has a namespace-based proposal that doesn't require any use 
of XML-namespace- like syntax (though it allows it to be used). The post 
is basically describing something very similar to what IE6 (even IE5?) 
does, something which has been studied in much depth before.

So anyway, as editor, I now have a choice: either I ignore the evidence 
that namespace prefixes are confusing to authors, or I don't use your 
proposal in its entirety. What should I have done?

Given that proposals equivalent to this one had been considered long 
before, why should your proposal change anything?

(Also: wouldn't sending proposals to the working group have been better? 
How are people on the working group supposed to know you blogged?)


> For starters, "You have never introduced new information" and "as far as 
> I can tell you haven't actually seriously considered what the proposal 
> is" are not conducive to a creating a constructive environment a 
> sustainable productive dialog.

Please, do point me to the new information, or indeed any technical 
information other than the URL to Microsoft's whitepaper, that you have 
brought forward. Maybe I missed it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 31 July 2008 23:12:34 UTC