Re: [Proposal] New Guideline 6 checkpoints (APIs, Infoset, DOM)

At 04:34 PM 2002-05-19, Ian B. Jacobs wrote:
>Hello,
>
>Based on discussion at the 16 May teleconference [1], I have
>drafted a new set of Guideline 6 checkpoints [2] for your
>review [2]. The proposal summarizes changes from the previous
>version of the checkpoints.
>
>I hope that we can discuss this proposal at the 23 May
>UAWG teleconference.

This is about as good as we are going to get.

In the ideal, for the target point on the horizon, what we want to be able to share programmatically is the model of the virtual world in which the application takes place, and to which the interaction relates [3].

In logical terms, this falls "somewhere between" the totally ordered, strictly hierarchical structure of the wire format [markup language] and the flat pixel plane of the actual display device in the default delivery context.  It has more structure than the pixel plane, but the structure is more "scene graph" than "document structure."  In fact it is the world evoked by the scene, not the view precisely, that is where the connection to the application world is made [4].

As we move to re-interpret the Web experience as multimodal interaction [5] as opposed to document access, the scene graph interpretation becomes more and more important.

But the event loop that provides the integration rules for behaviors in this scene is something we need then and we need now and is available in the neutral model provided by the W3C DOM.

The adaptive or alternate binding of the interaction will be as close to the [default = screen] author's optimal actual-interface details as we can keep it and make it work for the user.  This includes cases of more and less change.  Within this range, we need a statement of what must not change, and that is available from the DOM.

In terms of what is implementable today, we cannot ask for less than both: complete and correct information about the actual rendered form and access to some logical precursor structure, in as 'standard' a form as can be demonstrated to be a reasonable demand.

Al


>Thank you,
>
> - Ian
>
>[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0090
>[2] http://www.w3.org/WAI/UA/2002/05/api-proposal

[3] See the diagram depicting interaction, application, and computation worlds in 
http://trace.wisc.edu/docs/ud4grid/#_Toc495220373 .
Here the as-rendered information is of the interaction world, the HTML or XML hierarchy and order are of the computation world, and the structure and content to be preserved in alternate, adaptive bindings are of the application world.

[4] However, the remark that "you have no idea how X3D worlds are going to be rendered" and could be misleading.  There is geometry in the [application] virtual world that constrains all projections of the world that get rendered.  You know a lot about how it will be rendered.  There are residual degrees of freedom but firm constraints, too.  The geometry is not XML- or syntax-native, it requires processing the XML wire format in the context of a prior, or out-of-band-agreed, notion of geometry.  But the view-extraction routines of the delivery-context software and the application scientists developing the application share a common model of what geometry is as math and how the X3D format binds to this math model.

[5] The Multimodal Interaction Working Group is working on use cases and requirements, and the PF group is working with them.
http://www.w3.org/2002/mmi
The accessibility requirements here will contain content requirments strongly related to WCAG 2.0, player requirements strongly related to UAAG 1.0, architectural or binding-flow requirements related to what is visible in the draft XAG <http://www.w3.org/TR/xag>.

Some possible differences are related to unbundling the scene to deal with real-time streams flowing between sites, and the reality of portlets -- that objects in the scene may have largely autonomous support chains in the graph of services leading to the concrete particulars of the actual delivery context.

This can be correlated with lessons learned from what did and didn't get taken up in practice from the HTML4, CSS2 generation of specifications.  The priorities for programmatic access by AT in retrospect would appear to be *the lower ranks* of the part/whole-relationship graph (local aggregations), and *the upper ranks* of the generic/specific-relationship graph (general, broad types).  TITLE works in TABLEs to annotate form controls.  SCOPE, less so.  Indirection incurs risk.  Of the structure in the DOM, the lower levels of hierarchy are more likely to be critical to the comprehension of the content than the upper levels.  Example: Newspaper front page structure, with story fragments that wrap across columns and need to be kept together, nested in a page of stories which might as well be a bag -- you can random access among the stories and understand them fine.  But the syntax just knows order and hierarchy without distinction as to what order and hierarchy is essential and!
!
 wha
t is for the convenience of serialization over the wire.

The conventional wisdom would seem to be that the "Events in XML" module which is a based on the DOM2 capability remains the glue, even in strongly unbundled models of the objects in a scene framing a Web-delivered interaction.

 http://lists.w3.org/Archives/Public/w3c-wai-ig/2002AprJun/0057.html

Al

>-- 
>Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
>Tel:                     +1 718 260-9447

Received on Tuesday, 21 May 2002 11:08:25 UTC