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

HI Boris,

I don't think you're considering this from the needs of authors. The  
author is not interested in differentiating attributes that can be  
placed on local elements from those that can be placed on foreign  
elements (or all elements): especially when the vocabulary the author  
is using makes no such distinction.

On May 26, 2008, at 3:16 AM, Boris Zbarsky wrote:
> <snip>
>
>> 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.

That could be one approach, but either way could work. I believe right  
now that is what happens basically but that's not the language used to  
describe it.

If I have an attribute in the null namespace on an element in the html  
namespace, that attribute is treated like its from the html vocabulary  
(assuming its recognized or even required for UA processing or user  
comprehension). If a DOM script moves that attribute elsewhere, it  
remains in the null namespace, but now it would have to be interpreted  
as being from the vocabulary of the new element (e.g., the MyPool  
element). Sure, in the current situation the attribute doesn't change  
namespaces (it's always in the null namespace regardless of what  
element it's placed on). However, that simply sweeps under the rug  
that it still changes from one vocabulary to another. In what I'm  
proposing it would simply be made explicit in the namespace as well  
that the attribute was in one namespace and now its in another  
namespace (no different than the current situation where it was in one  
vocabulary and now it's in another because it was moved from one  
element to another).

Alternatively, the DOM could maintain the namespace of the attribute  
as it is moved from one namespaced element to another. I haven't ever  
found the need to move an attribute, so I don't even know what the  
current behavior is.


>> 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.

No that's not what I'm saying at all in my suggestion of fixing XML  
namespaces. An author can see immediately that fill has to share the  
same namespace with MyPot. If fill was from another vocabulary (like  
the swimming pool) it would have to look like this:

<MyPot SP:fill='...' />

Again, you're confusing this exactly in the way I said you were. My  
proposal is to get rid of the null namespace for unprefixed attributes  
and replaces it with a scoping of unprefixed attributes to their  
parent element’s namespace. I think this is much more consistent with  
the spirit of the XML namespaces recommendation where the idea of null  
namespace for unprefixed attributes appears entirely tacked on.

With what I'm saying, the unprefixed attributes do not take on the  
namespace of the default namespace in scope! The unprefixed attributes  
always take on the same namespace of their parent element (which in  
this case is the default namespace, but that's beside the point).  
That's a big difference. It means that vocabularies can be designed  
like XForms and like XHTML2 where attributes can be used on both  
foreign and domestic elements without any problem.  The only problem  
with doing it now is that it now causes attributes to end up in both  
the vocabularies associated namespace and the null namespace. If XML  
namespaces were fixed so that this didn't happen, then that problem  
would not exist. As it is now the only way to avoid this problem in  
XHTML2 and XForms is to always add a prefix even when it shouldn't be  
necessary (and sometimes making two prefix declarations for the same  
namespace). Forcing authors to have to add a prefix to keep things  
consistent completely eliminates the convenience intended for authors  
of being able to omit the prefix for these attributes in certain  
circumstances.


> 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.

That would remain the same under what I'm proposing, just that the  
attribute would not be in the null namespace but in the namespace of  
the parent element.

> 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.

How is that confusing. In XForms, the repeat attributes can apply both  
to XForms elements and to foreign elements. These attributes are drawn  
from the same vocabulary and mean essentially the same thing no matter  
what element they appear on. Yet the author can omit the attributes  
prefix on the XForms elements but not on foreign elements.  Why should  
that confuse authors any more than being able to omit the prefix on  
child elements in a newly scoped default namespace? Why is that bad  
vocabulary design to allow authors to use attributes with the same  
NCName in both situations where they mean essentially the same thing?

In the current broken situation these same attributes — from the same  
vocabulary with the same name and with the same meaning — end up in  
two different namespace (the null namespace and the XForms namespace).  
In what I'm suggesting the repeat attributes would always be in the  
same namespace throughout the document. Again to facilitate a one-to- 
one correspondence between vocabulary and namespace. To repeat, there  
is no reason to put attributes in the null namespace whatsoever.

> > 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.

I don't think you've failed to communicate. You're misunderstanding  
what I'm proposing. The only thing I can see that I don't understand  
is that you seem to place a great importance on using prefixes to  
differentiate those attributes that are only for domestic elements and  
those attributes that are for foreign elements. Yet there is nothing  
in XML namespaces that requires authors to follow that practice. The  
authors can omit the prefix or they can NOT omit the prefix (it is the  
author’s discretion). The attributes end up in different namespaces  
(null and otherwise), but their interpretation will remain the same  
because the interpretation is based on the vocabulary not the  
namespace. As the XML Namespaces 6.3 example shows the use of the null  
namespace for unprefixed attributes even permits the misuse of  
attributes by adding two of the same attributes from the same  
vocabulary on the same element. Hopefully no language design will take  
advantage of that blunder before XML namespaces can be fixed.

Take care,
Rob

Received on Monday, 26 May 2008 16:47:41 UTC