RE: extensibility of role/class/property/rel Re: Security Markup

Mark Birbeck wrote:
> Karl,
> 
>> but the issue, I have raised is about the second aspects, which is
>> the mechanism to prefetch values and their definitions in a user
>> agents. The same way, it is possible to fetch DTD, schemas, etc and
>> do something with them because the software knows the grammar for
>> reading a DTD or schema
> 
> I think we've gone about as far as we can at this stage of the
> language's development by adding the necessary hooks for such
> functionality--@role, RDFa, and so on. The next phase is to let
> people use it, and see what emerges. Taxonomies like the one Al
> refers to will begin to emerge, and then we can start looking at how
> we define the features of those taxonomies, how we locate them, and
> so on. But it would be premature to try to define this now, since we
> just don't have the experience. (And that definition need not be in
> XHTML 2 anyway, but should be a separate spec.) 

This is an interesting collection of comments Mark, as it relates to a
particular (nagging) issue I have with XHTML 2, @role, and in particular
@key as it relates to @role.  

You state (in regards to defining how users and user agents will interact
with @role) that "it would be premature to try to define this now", yet the
XHTML2 authors continue to insist that there is a pressing need to do just
that with the @key attribute.  You further state that it would be premature
since, "...we just don't have the experience...", which, given the
particular topic *I* keep bringing up, we do (Lord knows, I haven't shut up
about it...).  

We know currently that in our existing model (accesskey): 
	a) that often there are conflicts between author proposed
keybindings and 'mission critical' bindings within various Adaptive
Technologies, 
	b) we know that conflict resolution here is a mess, 
	c) we know that there is little to no standardization (UK
not-withstanding) between authors on an agreed-to set of keybindings for
various recurring functionality (skip navigation for example, or search) 
	d) we know that for various reasons, often the full set of "keys"
available to any given user may be restricted (cell phones,
internationalization issues, etc.)
	e) we know that functionality of this nature should not be in the
(x)HTML layer, but rather in the 'scripting' layer.  (And as an aside, there
has been some significant work in this area, manipulating accesskeys via the
DOM and scripting - see Gez Lemon's solution [my favorite] at:
http://juicystudio.com/article/user-defined-accesskeys.php), 
	and f) we have a proposed XHTML2 attribute that ignores all of this
in the form of @key - simply because there is a perceived (but un-documented
- 'cause I asked to see it) need for authors to set key bindings.  

Am I the only one who sees a disconnect from what you have said, and what I
am seeing?
      
> 
> So, the state of play is that we have a mechanism that can be used in
> a many ways...we have a 'hook'. This hook could be used simply as a
> container for a unique cookie that a browser or some server process
> understands inately (the QName as identifier), or the hook could
> point to some data to be retrieved and used by a process, such as a
> server-side transformation or dynamically in the browser itself to
> control behaviour (the QName as URI). But at the moment implementers 
> can choose how to use it.

Which is the key thing I have been arguing all along - set the hook but
leave it to the user-agents to decide how to interact with it.  To my mind a
'common collection' of key inter-navigational roles will emerge (there is
already a draft list), that may or may not need expanding upon - give this
to WAI if it needs work.  In these cases, referencing the Qname (as
identifier) *should* suffice as user-agents that can or must interact with
these types of 'hooks' will already be hard-wired or otherwise configured
(by the user?) to do so.  If you need to create and define a whole new
navigational hook (Qname) then you have the mechanisms in place to define
that new role, along with (to me) the appropriate place to suggest a hint,
as I interpret Al Gilman's recent post to suggest:

"Coming (with any kind of luck, soon) to a TR Page near you will be a
draft specification on "Roles for Accessible Rich Internet
Applications." ...  User agents can call on them for augmented
user coaching, and author tools can call on them as well to construct
prompts and menus for authors."


...and so, not to hijack this very interesting thread, tell me again why we
*NEED* @key?

JF
--
John Foliot  foliot@wats.ca
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca

Received on Tuesday, 22 August 2006 17:36:41 UTC