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

On Fri, 23 May 2008 15:25:13 +0200, <noah_mendelsohn@us.ibm.com> wrote:

...
> Also, and again others are more expert in the nuances, I believe that one
> refers to elements and attributes being "not in a namespace" as opposed  
> to being "in the null namespace".   The reason, I believe, is that a
> namespace suggests a single managed "space" of names.  Usually the
> assignment of names in a namespace is coordinated by a single party,
> typically the "owner" of the namespace name URI, or by several parties
> cooperating.  Conversely, there are zillions of attributes and elements
> named "A" in XML documents of many different sorts.  Collisions among
> those tags is in general not intentional or coordinated.  In that sense
> there is no null namespace, just tags "not in a namespace".

Hmm. Making an explicit difference based on some concept of how these  
things are intended to be used socially is not, IMHO, an entirely smart  
move.

Although in general I agree that better managed namespaces than the one  
whose canonical name is the empty string are desirable, the spec doesn't  
make any claims about how other namespaces should be managed. It does make  
it clear that there is a possible value for a namespace name which is the  
empty string. I noted in my first mail in this thread that a good design  
pattern for using this null namespaceis to provide some further kind of  
disambiguation (one that doesn't clash with the mechanism used for  
namespaces, of a prefix seperated by a colon) - and that if you don't need  
to work with the HTML legacy you probably should use namespaces for all  
attributes.

While  
http://my.opera.com/chaals/files/ThisIsMineSoLeaveItAlone/namespaces/something#  
is likely to be pretty much left to me to control, the namespace for  
Dublin Core is one where real usage is far less managed than the theory.  
dc:Author is actually a pretty common namespace-qualified term, despite  
not having been described at all by anyone who could be said to "own" the  
namespaces for Dublin Core.

> Also, to support self-description on the Web, you can put up a RDDL or
> similar document "at" the namespace name URI.  This can enable some  
> degree
> of automated processing of the markup (perhaps automated styling with an
> XSL stylesheet) even by user agents that have no built in "knowledge" of
> the namespace.  This clearly can't be done for names not in a namespace.
> The ability to support such self-description is among the reasons, I
> believe, that some members of the TAG find qualified names to be highly
> desireable.
>
> My purpose here is not to weigh in on the net pros or cons of aria-xxxx.

Nor is mine. I contend that the local name of an attribute is entirely the  
business of the people who mint the attribute - nobody complained about  
svg using fill-xxxx and font-xxxx. I am interested only in the discussion  
of how the aria attributes are assigned a namespace.

It turns out that there has been a misunderstanding in the PF group (and  
reflected at least partially in the XHTML2 group, and possibly others)  
which led the PF group to propose having two forms of the attribute - one  
in a namespace they minted, and another, with aria- added as a prefix and  
(to use your terminology) in no namespace - which means that the canonical  
names of the second form woul begin with "aria-" and have the empty string  
as their namespace qualifier.

The TAG proposed that instead the second form use "aria:" as a prefix, and  
asked what this would affect. Funnily enough, it has a nasty impact on  
namespace handling, since the colon is a reserved character that usually  
triggers namespace handling.

I am therefore (re-)proposing that the attributes be defined in a single  
form, with a set of local name that all begin with "aria-" (in an attempt  
to avoid clashes with other attributes whose canonical namespace is the  
empty string) and with the empty string as their namespace identifier, in  
order to work the same in both HTML and XML languages without requiring  
anyone to remember any special magic tricks for CSS, DOM scripting, or  
anything else.

It turns out that this matches what I understand has actually been  
implemented by at least 4 browsers, that it means there is a single form  
for each aria attribute that works wherever you want to use it, allows for  
naive copy-paste code development to work, and is entirely in line with  
the XML namespaces spec and its various implementations.

> Having worked for several years at Lotus, a company that sold software  
> for use by millions of end users, I'm very, very sympathetic to the
> pressures on companies like Opera that are well along in preparing to
> ship code.

If the standard and the implementations follow some route different to  
what is implemented, we regard incompatibility as a bug and will change it.

> Here I'm merely to discuss some of the issues relating to
> tags that are vs. are not in namespaces.

And I am here because I believe that (probably because we explained it  
badly) the PF group had not understood the proposal we had for ARIA to  
work in different languages, and therefore set up a more complicated  
version that caused people to react to its flaws, where it would have been  
better if they had challenged its assumptions. It seems that the PF group  
has now understood the original proposal as intended (what I laid out  
above), and I hope that the TAG will take that version as the basis for  
future discussion.

Note that I am not the chair of PF, so I cannot declare a consensus for  
that group. I am reporting my personal understanding of the rough  
consensus in that group. I believe that I am accurately representing the  
understanding of the various implementors of ARIA in browsers, although  
again I don't have any kind of formal mandate.

Cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Received on Friday, 23 May 2008 14:14:51 UTC