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

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

From: Laurens Holst <laurens.nospam@grauw.nl>
Date: Thu, 01 Oct 2009 11:15:47 +0200
Message-ID: <4AC47343.8010602@grauw.nl>
To: Adrian Bateman <adrianba@microsoft.com>
CC: HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>, Sam Ruby <rubys@intertwingly.net>
Op 1-10-2009 0:44, Adrian Bateman schreef:
> Tony has written up our thoughts on Distributed (or Decentralized) Extensibility in the attached HTML document. Tony is on vacation so I am posting on his behalf.
>
> We have included a base proposal with several optional components. The purpose of this document is to seed a discussion and we expect the discussion to drive improvements in the document.
>    

I think the approach taken is good and Base Proposal plus optionally 
Optional Component 1 would be my preferred way to deal with distributed 
extensibility.

However I have a comment on Optional Component 3; I do not think it is 
necessary to predefine these prefixes, as in HTML5 elements from those 
namespaces already have a predefined namespace derived from the element 
name and context.

Above I say ‘optionally’ the Optional Component 1 because I have doubts 
about how this interacts with the context-based namespaces that are 
currently in HTML5; it may be confusing that in some cases a namespace 
is ‘automatically’ assigned based on an element name, and in other cases 
this does (presumably) not happen.

When combining the current ‘auto-namespaces’ with default namespaces I 
am imagining you’d get rules like:

if (this.parentNode.namespaceURI == xhtml_ns and this.nodeName == 'svg') 
then this.namespaceURI = svg_ns
if (this.parentNode.namespaceURI == svg_ns and this.parentNode.nodeName 
== 'foreignObject') then this.namespaceURI = xhtml_ns

Etc., which seems to get really confusing. I think perhaps HTML5 should 
make a choice for the default namespace: either do it automatically 
based on the current rules, or use a default namespace mechanism as 
descriped in Optional Component 1, and not do both (unless you can show 
how it can work while at least retaining a semblance of consistency :)).

Not having default namespace would be acceptable to me, and I can see 
how the auto-namespacing feature of certain common (or rather, 
‘editor-endorsed’) vocabularies such as SVG and MathML is a good feature 
for novice HTML authors, although I have doubts whether those kind of 
authors will be able to deal with the complexities of SVG and MathML, 
but find namespaces too hard to understand.

Re. concerns that XML namespaces are too difficult for authors; what 
part of HTML5 do you think is /simple/ for authors? Really, HTML5 has 
such complexities (just to name one, <script src=""></script> vs. 
<script src=""/>, the latter failing rather miserably), I think you 
cannot defend lack of simplicity in XML namespaces… Plus, in XHTML use 
of namespaces is mandatory; in HTML5 you only really need to use it when 
creating extensions.

Re. differences in implementations; I think this is probably good, if 
there is little agreement between browsers about how those kind of 
elements/attributes are parsed into the DOM now, that means we have 
freeer reins in choosing a solution.

~Laurens

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com


Received on Thursday, 1 October 2009 09:16:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:08 UTC