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

Robert J Burns wrote:
>>  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.
> 
> There are already XML vocabularies that have these properties. XHTML2 is 
> one that I know of off the top of my head.

Would you mind pointing me at the relevant part of XHTML2?  I took a 
brief skim and didn't seem to see the part that defines a single 
attribute name that means the same thing both in the null namespace (on 
some elements) and in some other namespace (on all elements).

> The point is the concept of 
> a null namespace accomplishes nothing that couldn't better be 
> accomplished without it.

I disagree.  It accomplishes the clear separation of attributes that 
only mean something because of the element they're attached to from 
elements that mean something no matter what element they're on.

> (thus breaking the one-to-one correspondence of vocabulary and 
> namespace).

I don't see how it breaks such a correspondence to say that, for 
example, "the @type attribute on an element with localname 'input' which 
is in the XHTML namespace indicates the type of the input" as opposed to 
saying "the @type attribute in the XHTML namespace indicates the type of 
the input, but only when placed on an element with localname 'input' 
which is in the XHTML namespace".

> I'm not referring to the NS methods. I'm referring to the non-NS methods 
> which do not follow the spec

I am aware of only one common non-spec-following aspect of the non-NS 
methods in the browsers that implement namespaces at all: createElement 
in XHTML documents.  Are there more?

> No, I do not think any of the major browsers follow the DOM 
> recommendation on the non-NS methods in namespaced documents.

Again, details?

> The only other thing that I could think of that would break would be the 
> case where authors currently iterate through the attributes on an 
> element looking for those in the null namespace. This would break 
> because after fixing this problem, the attributes previously in the null 
> namespace would now be in the namespace of the parent element.

True.

> No, this wouldn't have to break anything either. This method would have 
> to be re-conceptualized as a convenience method where calling it without 
> a NS meant that the method used the namespace for the parent element.

So the namespace of an Attr node would change when it got moved from one 
element to another?  That's pretty odd behavior, to be honest.

> Why is it poor language design? Simply because it wants to take 
> advantage of the original vision of XML namespaces (a vision 
> circumvented by poor implementations who got the recommendation changed 
> for mere expediency)?

No, it's poor language design because it blurs the distinction between 
attributes that can be used on any element and attributes that can't.

Consider this markup:

   <MyPot fill="..."/>

Given your example, where "fill" in the swimming pool namespace means 
the swimming pool thing at all times, an author would have to do some 
digging in the document to figure out what default namespace was in 
scope on MyPot to decide whether the "fill" attribute is the swimming 
pool fill attribute.

As things stand, if you want an attribute to apply to all elements, 
that's immediately clear from the markup, because it has a prefix, so it 
doesn't matter what namespace your element is in; you just care about 
the namespace of the attribute.  If it has no prefix, then it only 
applies if the specification for the element's localname+namespace says 
it applies.

Maybe it's just my perspective, but the current setup only has the 
author confusion you have issues with (same attribute in different 
namespaces meaning the same thing) in situations when it has the much 
more important author confusion I've been trying to explain: that of 
having an attribute that can apply to all elements also apply to some 
special elements in a certain special (prefix-less) way.

 > I can't think of anything wrong with a vocabulary
> that uses attributes in this way except that it has issues with the 
> current broken state of XML namespaces.

In that case I've failed to communicate the conceptual difficulty such a 
setup would cause authors.  I don't think we'll get anywhere unless I 
manage to do so, and I'm honestly starting to not care about this 
discussion anymore.

-Boris

Received on Monday, 26 May 2008 03:17:29 UTC