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

Robert J Burns wrote:
> I don't think you're considering this from the needs of authors.

Actually, I am.  I took off my implementor hat completely for the last mail I sent.

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

Sure he is, if he wants to know what effect placing a given attribute on a given 
element will have or not have.

> 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 

No.  What happens is that the _element_ looks at its null-namespace attributes 
and does something with them.  No one other than the element bothers to look at 
those attributes.

For attributes that are namespaced, something would need to be done with them no 
matter what element they're attached to; the handling of such attributes needs 
to live outside the specific element.

>> Consider this markup:
>>
>>  <MyPot fill="..."/>
...
> 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.

Yes.  My point is that he CANNOT see immediately what namespace MyPot is in, and 
hence can't tell by looking at it what the fill attribute will do.

> Again, you're confusing this exactly in the way I said you were.

No, I don't think I am.

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

Yes, I understand your proposal.

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

You've said this repeatedly, in those exact words.

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

It's very much not beside the point from an ease of authoring perspective.

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

So some attributes in the swimming pool namespace will apply to all elements and 
some won't?  That seems even more confusing to me.

> How is that confusing. In XForms, the repeat attributes can apply both 
> to XForms elements and to foreign elements.

I don't understand why one has to draw the distinction rather than just saying 
it applies to all elements and being done with it.

> Yet the author can omit the attributes 
> prefix on the XForms elements but not on foreign elements.

And I think that's a mistake in the language design; it increases my confusion 
as an author if I have a mixed-namespace document.  I have to keep checking 
which namespace the given node is in to decide whether the include the prefix. 
Easier to just include it everywhere.


> I don't think you've failed to communicate. You're misunderstanding what 
> I'm proposing.

Again, I don't think I am.

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

I don't care what method is used, but I want to know whether the given attribute 
will have the effect I want on the given element.

-Boris

P.S.  Still waiting on the XHTML2 example you mentioned.  Given the repetition 
of arguments we've both already seen, I don't think there's much more point in 
me responding more to this thread.

Received on Monday, 26 May 2008 19:04:55 UTC