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

On 23 May 2008, at 10:02 AM, Charles McCathieNevile wrote:

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

interim status:

[I am the Chair of PFWG and I don't as yet have a consensus to  
declare on this point, but...]

I would like to support the history as Chaals has recounted it above as
substantially accurate.  In particular as to past shortfall in  
understanding
and that we are actively considering fresh wording in this area that  
he has supplied.

Al


> 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 15:51:27 UTC