Re: null namespace Re: Next steps for the ARIA syntax discussion

Robert J Burns wrote:
> I gave an example earlier, using Charles swimming pool example.

Are you referring to 
<http://lists.w3.org/Archives/Public/public-html/2008May/0474.html>?

If so, that doesn't seem to actually give an example of a problem.  Such
an example would require an actual definition of an attribute with a use for it.

If I were defining a SwimmingPoolControlML and had a "fill" attribute on MyPool, 
that doesn't mean that there would be a "fill" attribute in the 
"SwimmingPoolControlML" namespace that could be stuck on random html:divs.  If I 
did want to define an attribute that allowed to indicate a swimming-pool fill 
level on arbitarary elements (which doesn't seem like a reasonable use-case to 
me, I must add), I'd put it in a "SwimmingPoolControlML" namespace and not 
define a special "fill" attribute for MyPool elements.

> Your example of HTML and XHTML was 
> not convincing however since you're saying that you made it work that 
> way (where the NS method works in both for element but not for 
> attribute)

The NS method just follows the DOM spec.  If you create an XHTML-namespace 
element it behaves as XHTML should.

> for compatibility despite the DOM recommendations.

Nope.  It just follows the DOM recommendation.

> Obviously the same could be done for attribute as was done for element. I think 
> we're simply talking past each other now, and I don't know how to break 
> the log jam.

Again, I agree that if all UAs at once changed their DOM implementations, CSS 
selector matching, and parsing, and if at the same moment we revved all the DOM 
specifications and the CSS namespaces draft (now in CR) incompatibly, and 
convinced all the non-browser DOM implementations to change too, then we 
wouldn't break too much.  Just anyone who uses setAttributeNS and passed "" as 
the first argument, anyone using a non-updated XML parser, and maybe a few other 
things.

But I don't see a win to doing that, and we'll _never_ get buy-in from the 
hundreds or thousands of entities that would need to perfectly coordinate to 
make this happen.  At least in part, because they don't see a win either.  But 
even if there were a win, this wouldn't be a feasible undertaking.  Undoing 
history is very hard.

> My extension of Charles swimming pool example should suffice.

As far as I can tell, that extension is just poor language design.

> Except for authors and authoring tools dealing with an attribute (e.g., 
> myattribute) from a vocabulary (e.g., myvocabulary) where the attribute 
> can be placed on foreign vocabulary elements.

That's what I'd like an example of, to be honest.  It seems to me that any 
attribute that's designed to be placed on random elements should be namespaced 
(we agree on that!) and then just placed on whatever elements you want to place 
it on.  Like the way xml:id works, say.

> <root-element
> xmlns='schema://someuri'
> xmlns:my='schema://myuri'
>  >
> <their-element my:myattribute />
> <myelement myattribute>

So this language defined both a 'schema://myuri'!myattribute attribute _and_ a 
myattribute attribute on 'schema://myuri'!myelement elements?  Again, it seems 
like poor language design to me; I'd just define the former.

> Now myattribute from myvocabulary exists in two separate namespaces — 
> even though it is from the same vocabulary in both cases and its 
> semantics are the same in both cases.

Again, that's the fault of the people designing the vocabulary, no?

> It almost completely undermines the convenience of omitting the prefix 

The convenience is there for attributes that are NOT supposed to be used with 
random other elements.

> The claim that it cannot be fixed is not accurate either.

The claim is that "fixing" it involves incompatible changes that will break 
existing content even if we change most of the infrastructure of the web in 
lockstep in all the UAs involved.  That's not the same as "cannot be fixed" but 
rather "'fixing' it is not practical".

> The claim derives from confusing prefix and namespace and from confusing the 
> scoping of attributes with needing them to be in the null namespace.

I don't think there's any such confusion in my mind, at least....

> I've been providing examples, but no one has said why those examples are 
> insufficient.

See above.  Again, I agree that one _could_ come up with a language in which the 
same attribute localname can be used both in some nonempty namespace (on all 
elements) and in the empty namespace (on some special elements) to mean the same 
thing.  What I want to know is _why_ one would create such a language.

-Boris

Received on Friday, 23 May 2008 18:35:41 UTC