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

Hi Boris,

On May 23, 2008, at 6:34 PM, Boris Zbarsky wrote:

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

There are already XML vocabularies that have these properties. XHTML2  
is one that I know of off the top of my head. And I know I've seen it  
elsewhere, but can't recall right now where. The point is the concept  
of a null namespace accomplishes nothing that couldn't better be  
accomplished without it. And there's no reason future vocabularies  
should not be designed that way (except that XML namespaces are broken  
and need to be fixed). You haven't listed one reason that the spec and  
the implementations should put unprefixed attributes in the null  
namespace (thus breaking the one-to-one correspondence of vocabulary  
and namespace).

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

I'm not referring to the NS methods. I'm referring to the non-NS  
methods which do not follow the spec and currently are not  
interoperable across the major browsers. There's also no reason the  
DOM spec could not be updated to accommodate the repair of XML  
namespaces. We need to update it anyway since the implementation of  
the non-NS methods are currently not interoperable and not following  
the spec.

>> for compatibility despite the DOM recommendations.
>
> Nope.  It just follows the DOM recommendation.

No, I do not think any of the major browsers follow the DOM  
recommendation on the non-NS methods in namespaced documents. I will  
admit that treating the NS methods for attributes as convenience  
methods — i.e., scoping the referenced attribute to the parent  
element  when the namespace argument is null — would prevent authors  
from using attributes from a vocabulary left intentionally in the null  
namespace on elements not in the null namespace. However, that to me  
sounds ill-advised anyway and something I doubt many authors are doing  
now (if any).

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.

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

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.

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

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

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

I don't see what's wrong with such a language design. I can think of  
many reasons a language might want to do that. XHTML2 proposes doing  
this (and before simply bashing XHTML2, as so often happens here, how  
about explaining why its bad vocabulary design). I think XForms may  
also use this pattern. It's a design pattern that is an important part  
of the original vision of XML namespaces where different vocabularies  
can be mixed together in a compound document. It is a design pattern  
that would be fully facilitated by simply fixing this misguided null  
namespace for unprefixed attributes.


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

No it's not bad vocabulary design. There's no reason not to do that,  
except that it conflicts with the current broken state of XML  
namespaces. I should add a state that only exists because implementors  
wanted an expedient solution over the correct one (because they didn't  
want to follow W3C priority of constituencies and put authors ahead of  
mere expediency).

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

No, the unprefixed attributes convenience is there so that authors do  
not have to repeat the prefix on attributes in the most common  
situation where the attributes will share the same vocabulary (and it  
should be namespace too) with the parent element. It's should be  
thought of as another part of the scoping of namespaces within XML  
namespaces.

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

No, you haven't listed one change that would have to be done in  
lockstep (for all implementations together) or would make fixing  
impractical. Of course an implementation would have to make the  
changes to the DOM and the CSS at the same time, but that is not very  
unusual in updating or fixing an implementation.

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

There has to be or you wouldn't be making these claims about the  
difficulties in fixing this that you're making. :-)

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

But again, fixing it would effect few if any authors and little if any  
existing content. You haven't pointed to one thing that is bad about  
the vocabulary design (other than it doesn't work very well with the  
broken an inconsistent implementation of XML namespaces).

What I'm suggesting is this:

• unprefixed attributes should be added to parent elements in the same  
namespace as the parent element
• DOM manipulation of attributes should ensure that when methods do  
not specify a namespace, the method should infer the namespace of the  
parent element of the attribute (attributes without parent elements  
and without a namespace specified would be in the null namespace)
• CSS3 selectors (still in draft status) would be reconceptualized to  
match the newly repaired XML namespaces so that using the example from  
the CSS3 draft:

> CSS examples:
>
> @namespace foo "http://www.example.com";
> [foo|att=val] { color: blue }
> [*|att] { color: yellow }
> [|att] { color: green }
> [att] { color: green }
>
> The first rule will match only elements with the attribute att in  
> the "http://www.example.com" namespace with the value "val".
>
> The second_AND FOURTH_ rule will match only elements with the  
> attribute att regardless of the namespace of the attribute  
> (including no declared namespace).
>
> The _THIRD RULE_ will match only elements with the attribute att  
> where the attribute is not declared to be in a namespace.

These CSS selectors could be changed slightly to be more consistent  
with the current CSS3 selectors draft, however, I think making [att]  
select attributes regardless of namespace will break less content and  
confuse fewer authors than making [att] select only on attributes  
whose namespace is the same as their parent (which would be another  
way to go more consistent with the current CSS3 draft).

Making these changes would mean the repair of XML namespaces. It would  
also mean that virtually no existing content would break. I really  
don't see any downsides, except the few DOM authors effected by  
iteration looking for null namespace attributes that are now no longer  
null. The upside is that authors can now fully mix vocabularies —  
including attributes where appropriate — and not end up with those  
attributes in two separate namespaces (though derived from the same  
vocabulary).

Take care,
Rob

Received on Saturday, 24 May 2008 10:23:38 UTC