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

HI Boris,

On May 22, 2008, at 4:16 PM, Boris Zbarsky wrote:

> Robert J Burns wrote:
> > The spec actually says it both ways (as null URI and according to  
> the
> > element they are attached to).
>
> That's talking about two different things.  The exact quote from http://www.w3.org/TR/REC-xml-names/#defaulting 
>  second paragraph is:
>
>  A default namespace declaration applies to all unprefixed element
>  names within its scope. Default namespace declarations do not apply
>  directly to attribute names; the interpretation of unprefixed
>  attributes is determined by the element on which they appear.
>
> The following paragraph then says:
>
>  The namespace name for an unprefixed attribute name always has no  
> value.
>
> The key here is what "interpretation" means.  Basically, all this is  
> saying is that the meaning (semantics) of an unprefixed attribute  
> depends on the element it's attached to.  If you have a "fill"  
> attribute on a <ge:laundry-machine> element, it might describe the  
> level to which it's OK to fill the tub.  If you have a "fill"  
> attribute on an <svg:path> element, it might describe the fill to  
> apply to the path.
>
> For a prefixed attribute (one which is in some namespace), on the  
> other hand, the meaning (semantics) is generally defined by whatever  
> entity defines the prefix.  An xlink:href always points to some  
> resource, no matter what element it's on.
>
> No contradiction here; just have to keep in mind that there are two  
> questions to be asked about an attribute: 1) "What namespace is it  
> in?"  2) "What does it mean?"  The spec talks about the answers to  
> both questions.  I absolutely agree that it could be phrased more  
> clearly.


I understand how you're reading it (with no contradiction), but I'm  
saying it is a mistake to read it that way. Remember the W3C has a  
priority of constituencies it tries to follow: one should keep this in  
mind whether writing a W3C recommendation or implementing one. That  
priority is: user -> author -> implementation -> specification  
authors. When an implementor reads the spec (especially a W3C spec)  
that should be foremost in their mind in shaping their reading (not  
trying to force a construed reading that avoids contradiction). So if  
one reads the spec thinking about its purpose — allowing authors to  
create compound documents from separate vocabularies — then its clear  
that there is an error in the spec that can't simply be resolved by  
saying: "technically there's no contradiction". If an attribute is to  
be treated as from a certain vocabulary, then why should it be  
appearing in separate namespaces? What purpose for users or authors  
could that possibly serve (or implementors for that matter)?


> > And implementors followed the
> > inappropriate way the spec describes (perhaps not anticipating the
> > problems it would create).
>
> To be honest, I'm not aware of any serious problems this has  
> created, and I know of a few it has avoided...

Well, that's the question I keep asking. Could you share with me a few  
of the problems the null namespace avoids. I'd be happy to concede to  
your position, but I've been hard-pressed to find what advantages  
there might be.


> > I seriously doubt correcting that mistake in
> > current implementations would lead to serious problems.
>
> It'd break existing script working with setAttribute(NS) in  
> application/xhtml+xml, SVG, MathML, etc documents.  And it would  
> complicate UAs somewhat (e.g. UA stylesheets for HTML/XHTML would  
> become more complicated). And it would make it more difficult to  
> author content that satisfies XHTML 1.0 Appendix C and can actually  
> be served as text/html _or_ application/xhtml+xml (because you'd  
> have to write the stylesheets differently).  And of course it would  
> be a good bit of work to change the UAs to do this.
>
> Frankly, I can't think of much more serious problems than that which  
> a spec change _could_ cause, short of security bugs.  I'll grant  
> that this change _probably_ wouldn't introduce security bugs.

I'm not sure this is the case. There may be some other minor problems,  
but it certainly wouldn't have to create problems with since the DOM  
implementation could be changed the same time the parsing  
implementation was changed. Since I'm saying that we should simply  
stop having elements or attributes in the null namespace (within a  
compound document), then it may not be such a difficult problem.

>
> > However, correcting it would make things work much easier for  
> authors and
> > authoring tool developers.
>
> It would make it harder to author XHTML.  What would it actually  
> make easier? I'd love to see an example...

I've already said what would be easier: that is it is much easier for  
authors to not have attributes from the same vocabulary in two  
different namespaces. How would it make it more difficult to author  
XHTML? I think part of the problem here is that you've become so  
accustomed to thinking about things in one way that you're not  
considering how this could be different.


> > No, the spec says two different things
>
> As I said above, it's talking about two different things.  It  
> doesn't say two different things about the same topic.

It's talking about two different things technically, but those two  
different things should be mapped one-to-one to make namespaces work  
smoothly (and other parts of the spec make this clear).

> > and implementors went with the wrong one. Why that is I don't know
>
> Because they understood what the spec actually says?

Maybe, but it also may be early implementors changed the spec. I don't  
know the history of it, but the part about null namespace strikes me  
as slapped on and sort of "which one of these things is not like the  
others".

>
> > No, I think it is a major headache for authoring situations.
>
> Again, I'd love to see a specific example where this is a problem.

It's been a while since I've worked on this, but surely you can  
understand that having the same attribute in separate namespaces is a  
problem. Why would an author or user (or implementor or spec writer)  
ever want that? I'm sure if it was fresher in my mind I could  
construct some problem examples. The point is the null namespace  
needlessly makes authoring compound documents more difficult (for no  
reason as far as I can tell). Also, since the XML namespaces  
recommendation is a very forward looking recommendation the problems  
the null namespace creates will become more aggravated the more  
authors try to push the bounds of XML and XML namespaces. Aaron  
mentioned XSLT. XEvents is another XML vocabulary involving attributes  
that can be used on both foreign and domestic elements.

I think the problem can be fixed now (rather than later) with serious  
damage to existing content. However, it needs to be fixed especially  
before CSS3 namespaces become widely used (that's an area where I  
think it could require some transitioning work).

> > It should be users, then authors, and then implementations.
>
> We agree on something!
>
> Of course if implementations don't (e.g. can't) implement the spec  
> as written, that's no good for authors either.

I think you're underestimating implementors. Sure there's a problem of  
group think where one implementor starts off (perhaps doing something  
wrong) and the other simply follow suit. However, there's nothing to  
prevent an implementation that makes sure every element and every  
attribute in a compound document is in a namespace.

> > Of course getting a group largely controlled by implementation  
> developers
> > leaves that largely up to the honor system.
>
> Indeed.

Agreed again.

Take care,
Rob

Received on Thursday, 22 May 2008 18:57:36 UTC