Re: Role and Access attribute modules and namespaces

Actually, Henri's issue is orthogonal to the issue I was trying to 
address - that of potentially permitting chameleon namespacing in our 
modules.

W.r.t. Henri's third suggestion: We are producing XML modules, and in 
the XML world people use namespaces.  At least, that's what I think. We 
are NOT proposing the use of QNames in attribute values (separate 
discussion).  We are saying that our attributes exist in our namespace, 
and other grammars can use those attributes to get our semantics by 
referencing the attributes in their qualified form.  I don't think 
anyone in our community would feel that defining attributes in "no 
namespace" is something the XHTML Working Group should be doing.  We are 
not chartered to push stuff outside of our namespace (nor define so 
called "global" attributes), and I think it would be a very bad idea to 
do so anyway. 

Moreover, our efforts to "export" attributes is not something that is 
new at all.  We have always done this.  All I was proposing was that we 
consciously recognize that in the case of the new modules we are 
producing, those attributes are only "exported" through their use as 
qualified names in our namespace.

Namespaces are not bad.  I know that lots of people seem to think that 
they are, but typing xh:role is not a lot more work than typing role. 

Richard Schwerdtfeger wrote:
>
> Does not address Henri's third suggestion:
>
> <henri>
> I'm curious why a third way isn't mentioned:
> 3) Non-Namespaced Attributes for both role and states/properties with  
> the latter prefixed with "aria-" (and no qNames in content but opaque  
> strings):
> <svg
>  xmlns="_http://www.w3.org/2000/svg_"
>  xmlns:xlink="_http://www.w3.org/1999/xlink_">
>  <g role="checkbox" aria-checked="true">...</g>
> </svg>
>
> Pros:
> * Matches what has recently been proposed for (X)HTML5 and XUL.  
> Good both for implementation and author skill portability.
> * Fewer namespaces to deal with (i.e. easier).
> * Copy-paste-friendly.
> * DOM-friendly. (qNames in content are *bad* in the DOM.)
> * Not a chameleon namespace per se. The attributes would be in no  
> namespace in XHTML5, SVG and XUL.
> * Semantics and processing can still be imported by normative  
> reference from wherever they get defined for HTML5. No need to spec  
> all this in the SVG spec.
>
> Cons:
> * Not what the WAI PFWG draft currently says.
> * Unorthodox in terms of XML architecture.
> </henri>
>
> Thoughts?
>
> Rich
>
>
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
> Chair, IBM Accessibility Architecture Review Board
> blog: http://www.ibm.com/developerworks/blogs/page/schwer
> Inactive hide details for Tina Holmboe <tina@greytower.net>Tina 
> Holmboe <tina@greytower.net>
>
>
>                         *Tina Holmboe <tina@greytower.net>*
>                         Sent by: public-xhtml2-request@w3.org
>
>                         10/16/2007 10:08 AM
>                         Please respond to
>                         tina@greytower.net
>
> 	
>
> To
> 	
> Shane McCarron <shane@aptest.com>
>
> cc
> 	
> XHTML WG <public-xhtml2@w3.org>
>
> Subject
> 	
> Re: Role and Access attribute modules and namespaces
>
> 	
>
>
>
> On 16 Oct, Shane McCarron wrote:
>
> > So, I propose that we say this:  Elements and Attributes declared in
> > the XHTML namespace exist in that namespace, and nowhere else.
>
>  This makes sense to me. It's also good to have it said explicitly.
>
> -- 
> -  Tina Holmboe      Developer's Archive           Greytower Technologies
>                   http://www.dev-archive.net      
> http://www.greytower.net   
>
>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Tuesday, 16 October 2007 20:19:50 UTC