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

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.

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

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

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

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

 > and implementors went with the wrong one. Why that is I don't know

Because they understood what the spec actually says?

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

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

Indeed.

-Boris

Received on Thursday, 22 May 2008 16:18:00 UTC