access to machine comprehensible type information for events?

1.  Point of possible agreement.  In the oral discussions on the 17th, I
thought that there was some agreement that "name" as what comes back in the
list of events could be replaced with "description" as a friendly amendment, so
far as the DOM implementation is concerned, so long as the description is there
for the DOM to grab from somewhere, and it doesn't have to make it up.

2. Point of possible disagreement.  Some opinion was voiced, I believe, to the
effect that we simply aren't interested in firing events that go with devices
not in use.  I would disagree.  Populating event data by algorithm, heuristic,
and dialog is something that assistive technology might indeed take on. 
Knowing what you have to produce may influence what the approach is.  Compare
with the "mouse grid" method of arming active elements in a scene used in voice
command.  Here it matters that the objective is to isolate an active element. 
Voice input into MouseKeys would be much more indirect and tedious.  So
creating a virtual rubber band by progressive refinement is a better approach.

On the premise that there is non-trivial likelihood that AT would wish to
syntesize events not native to the incumbent operating environment (e.g. no
pointing device in use) we are interested in knowing the _type_ i.e.
information content of and event so that when the event is spawned it can be
populated with sensible information.

What I don't know is the status quo on this point.  How do scripts know what
data they can look for in an event?  Or do they just query system state?  If
the pointer location is something the script needs, does it get it from the
event or from the environment?  How would an assistive software routine with
DOM access take the name of an event type and learn the data structure
characteristics of that event type?

The high-end response, here, would be to recommend that events in XML use the
'model' module from XForms, or some schema discipline like that, to introduce
XML-native definitions of the events that pass through the environment of an
XML document, and to which the XML document attaches associations.  This would
establish a common basis of understanding between script writers and the
writers of assistive interlopers and the delivery context bindings that also
manipulate these events.

Is this functionality already implicit in the status quo?  If so, how does it
work?

Al



At 11:19 AM 2002-02-19 , Ray Whitmer wrote:
>Charles McCathieNevile wrote:
>
>>OK, first to make sure that I understand clearly what is being proposed -
>>otherwise my response to it is misinformed.
>>
>>  With Ray's proposal we are asking people to create two DOM events (as
>>  specified), which means that they are using existing DOM2.
>>
>>  If we include this in the specified set of things we expect to be
>>  implemented (for example by User Agents) then doing so is not difficult
>>  for a DOM implementation.
>>
>>  These events will allow a user to right-click (or otherwise appropriately
>>  arm) an object, and receive a list of the event listeners which are
>>  listening to that event (somewhere in the bubble/capture phase)
>>
>>  So for existing Web content, the user could expect to see events with
>>  names like click, mouseover, etc. But it is trivial to write events that
>>  have useful names instead, which solves the future case, it is easy to
>>  write events with real names that fire the events currently called click,
>>  focus, etc, so current content can readily have the new system ayered
>>  over it, and users will learn the small range of behaviours that is
>>  mostly associated with the current device-based event listener set in
>>  practise.
>>
>>If all the above is true (i.e. if I have correctly understood what Ray was
>>proposing), then I propose that WAI adopt the following approach:
>>
>This proposal of two new events does not address existing web content by 
>itself.  For existing web content we have the methods in the DOM Events 
>specification that we recently defined and those that were there before. 
> The two techniques may be used together -- the methods for non-semantic 
>events that the agent knows how to fire, and the new events for semantic 
>events with better-understood activation models and better descriptions.
>
>These new events are clearly semantic.  We are not putting both semantic 
>and non-semantic events into the same enumeration because they are 
>complimentary, although the agent may present them together.  If they 
>were enumerated together without distinction as to non-semantic type, it 
>would not work because the event structure passed to semantic events is 
>different from the structure passed to non-semantic events.  Semantic 
>events will typically have semantic names.  Non-semantic events will be 
>named however the agent likes (including "click") since the agent is 
>testing for the presence of a specific type of event which is 
>event-specific in how it is fired.
>
>>1. We adopt Ray's proposal. We ask that it be developed as part of the DOM
>>specifications, and that it be incorporated as part of user agent
>>requirements / techniques for providing access to interactivity.
>>
>>2. We further request, of the XML events group, that their namespace include
>>a method for referring to a description of an event - prefereably by IDREF /
>>URI so it can be usefully an attribute, although an element (such as the desc
>>child of the animate element in SVG) which can have parseable XML content or
>>have an xlink:href pointer would be even better. (I don't think that it fits
>>all the use cases XML events is required to support. Further discussion might
>>suggest that both should be available in the namespace). I believe that this
>>information would the be queryable using the existing DOM, although again we
>>would have to specify it as a user agent requirement / technique to be
>>implemented.
>>
>It is good to be able to do semantic events declaratively with xml 
>events and have such things handled automatically, but I believe it must 
>be compatible with the procedural way of enumerating events, which is 
>more functional, even if more complex.  For example, declarative XML 
>semantic events might be a shortcut that underneath, wraps the simpler 
>handler declaration in the required procedural agents -- not unlike what 
>happens today with HTML declarative events mapping to calls to add the 
>handlers.  Pages could still use the procedural agents.  The 
>accessibility agent does not directly need the declarative form, because 
>the enumeration event is giving it all the info it needs.
>
>You probably already realize this, but the design of the two events was 
>intentionally such that there was no declarative enumeration of event 
>names and descriptions is required.  Instead, an event listener, similar 
>to the one that will handle the semantic event, enumerates which events 
>are available on a particular node and its descendants.   There are good 
>reasons for this:
>
>1.  It permits web content developers to develop content using the new 
>events that can be used by semantic-aware agents inside of existing 
>browsers.
>
>2.  It permits features to be dynamically judged "available" or 
>"unavailable", based upon the state of the document.  For example, 
>perhaps I have a button that sums a column.  I want the column-summing 
>feature to only appear when there are actually values to sum.  Or 
>perhaps the form cannot be submitted without fields passing 
>verification, etc.
>
>3.  A semantic event handler can be declared on a single node anywhere 
>in the hierarchy and choose to accept or reject events targeted at all 
>descendant nodes.  It only makes sense that you can declare a handler on 
>the same node that enumerates the types of events handled for the 
>descendent nodes or we are back with the same problems of not really 
>knowing which nodes accept which semantic events.
>
>>This should give us a method for finding out what events are available at a
>>particular element which is easily implemented and covers past present and
>>future cases, and a method for future cases that allows us to get further
>>information about an event than a name, for users who need it. (Compare the
>>model in xforms of hints and help as another example of this approach).
>>
>>This proposal might still contain errors of fact - please check it...
>>
>I agree that XML events is a great opportunity to make things easier and 
>give browser developers an incentive and easy path to add support for 
>semantic events, which would also work without browser intervention 
>(given DOM level 2, and better in DOM level 3) but could make the 
>declarations easier and support something like a right-click even when 
>there is no agent running.  We need a very smooth path, with clear new 
>standard milestones along the way to really get it functional, such as 
>XML Events presents.
>
>Best regards,
>
>Ray Whitmer
>rayw@netscape.com
>

Received on Thursday, 21 February 2002 10:16:41 UTC