Some comments on DISelect

Preface

Author Proposes, User Disposes

The basic idea is to support UAAG10, Guideline 2 "Ensure User Access to All Content."   The processing of DISelect semantics is intended to be able to be performed either on the client side or the server side.  The critical fact is that it is performed for each user hit on a resource; whatever is known about the delivery context is known before this processing takes place.  That means that it creates a great opportunity and should fall heir to the UAAG requirements wherever the UAAG requires that something be configurable to user need and/or preference.  This means that the hooks have to be there to let the user profile the down-select to pick *their* best, or multiple of the available options, regardless of the precepts and rules established by the author.

User experience with real web content has shown that people with disabilities often find content targeted to WAP devices, or content targeted for printing, adaptive over the baseline user experience profile.  The author cannot be expected to fully understand the factors active in the delivery context that make one option superior or inferior.  So the processing environment should make all choices at this stage advisory; not binding.  This is not data in XML, this is user interface in web dialogs.  This processing needs to be better integrated into a mixed-initiative process by which user and server resolve the user experience profile to mutual satisfaction.

Access Ideal

One revision of this technology that some might consider best for access would be:

Access issues

User overriding the author's precept

Author influence over content selection must be modified to make the balance and flow of decision resolution approximate what has been set out for the 'override' attribute in SMIL.  The basic idea is that the easiest thing for the user to get is exactly the way the author envisioned it, but that the functions are there for the user to inspect and override any choices between alternatives.

I suspect that the DI WG meant to support this capability by including the option of client-side application of DISelect processing.  What appears to be missing is the mechanism by which the client gains control of DISelect processing and the server responds by deferring DISelect processing to the client which has expressed both the capability and the preference to carry out this processing.  Demonstrating this negotiated handoff is a function that should be on the checklist for the CR -to- PR transition.

Interactive option

The dialog gesture that is missing from the processing concept of this format is the occasional use of a menu by which the user interactively selects an option.  This has to be use sparingly; automation will allow us to make the user experience personalized much more than users could manage in this way; but the fabric supporting the automated personalization must retain the support for the "menu of minimized choices" alternative so that the user is not cut off by the severely limited concept set included in the 'starter functions' set out here.

This may be important authomation for the evolutionary introduction of this capability, so that there is a standard preform for the user to communicate preferences to the server via a form as an alternative to CC/PP.  That could be achieved by a top-level application of this
"menu-ize" recovery option.

Reword to eliminate "CSS class" terminology

The discussion of the HTML 'class' attribute as "CSS class" in section 7.1 is counter to the correct use of HTML and CSS.  In the correct use, the 'class' marks denote content characteristics and the style *rules* in the stylesheed allocate presentation effects to the content fragments based on the semantic (meaning-oriented) information in the 'class' marks refining the path, element-type, etc. information sensed by selectors.

DISelect to appendTo, not set, host 'class' attribute

The 'class' attribute in XForms host languages and HTML historically is a collection of category-membership marks.  In other words, the 'class' mechanism provides multiple-heredity refinement of the object class system starting from the element type defined in the format syntax.  Well-ordered presentation processing downstream from this content selection function requires the same content information as is implicit in the design of the content-selection thresholds.  Nothing in the design of the content-selection criteria should be presumed to know that certain informationi is *not* required for later adaptation of the presentation.

In this context it would be more appropriate for this phase of processing to add to the 'class' marking of a host element, not rewrite it.

This is not a change to the AVT capability, but the example should be rewritten to show accessible practice in this regard.

What may appear in an 'expr' guard expression

Several of us took away the impression that all that could appear in a guard expression (inside the syntax set out in section 8.1) was glue logic, literals, and calls to the "starter set" functions modeled after CSS Media Queries.  I have been advised, that no, anything in the delivery context is nameable in admissible XPath expressions, as well as element properties for elements in the host-language document being processed.

Please a) confirm by your own review of the specification logic and b) exemplify in examples in the document the use.

Further, please mine the results of the "metadata for content adaptation" workshop for good content properties to use in illustrations.  And mine the IMS Accessibility Profile for good delivery context facets to illustrate.

Issue: How to get this across

Device Independence and Accessibility will both be better served by the author's use of basic, objective content properties (that would port unmodified to address an expanded list of delivery contexts) rather than hard-wired thresholds to compare delivery context facets to.  But most people will first do the least that they can to get up and running.  So there is likely to be a lot of dysfunctional code fielded before people learn how to use this capability to best effect.  And people with disabilities may be left out in the cold during the interim.   Just how to get best practice and its advantages for the author across is something that we should discuss.

The 'em' length unit.

The list of starter XPATH functions must be expanded to support all size calls with a length unit of 'em.'  Actually, the comment is "support the full css2:length production."  Note this inclues 'em,' 'ex,' as well as 'px.'  The 'em' unit in particular is required to support the election of brief-text options when the user has elected large fonts, despite what on first glance would seem to be an ample screen.

The function description should then be expanded to make clear (with the concurrence of CSS WG) that when ci-cssmq-grid is True, the size queries will yield numbers (the number of cells per line for width and lines per display for height) when the size functions are queried with 'em' as the unit and return errors otherwise.

Further Feature specifics

Inconsistent show/hide policy

If the 'expr' attribute is absent, even in an 'if' element, it is not an error and the content is retained.
If the 'expr' attribute is set to an XPath expression that experiences a non-recoverable evaluation error, the whole process is aborted, denying the user access to this content.  This is biased too far toward author control of the user experience against the user's right to access the information offered.  To take advantage of user exerience profiling that works for them, people with disabilities need an overriding right of access to the content, as set forth in the UAAG quite clearly.

process=once

When the DISelect processing is being performed client-side, this would appear to bar the user from obtaining some adjustments to the user experience that they would otherwise be able to reach by adjusting preferences and re-processing.  What is the motivation for this option?  Is it for efficiency when the author is confident that re-evaluation will yield the same result?  If so, why not state the clause in terms of "if process=once then the processor MAY, when the document is reprocessed, retain the old value established the first time processed and not re-evaluate the expressions in the scope of this [directive]."  Then the client-side processor will be sure not to be functionally impaired by the semantics of this feature.

General Quality Issues

So termed here because they affect all users equally, without prejudice to access by people with disabilties.

MUST use namespaces

Where it says "XML Processors must use the XML Namespaces mechanism [XML Names] to recognize elments and attributes in this namespace."  The language is unclear.  Do you not contemplate host languages that implement this module within their own namespace, as with XForms in XHTML 2.0?  Would it not be more clear and accurate to say "Conformant processors must recognize local names bound to these namespace URIs by [prefixes and] namespace declarations as prescribed in [XML Names] as representing the names as defined in this specification," or some such?

Note: this has to be a generic issue, given the general broughaha over how much semantics goes with a namespace declaration.

Importing Attribute Value Templates

The intent to import a capability from XPath is clear but it would seem that the language used to say this is imprecise.  Isn't there a more precise way to say just what is being imported, here?

The Delivery Context namespace

Is this used anywhere in this specification?  Are you trying to reserve this URI?  What does this URI have to do with "conformant processors" of this specification?

Content of the 'if' Element

The specification prose says that an 'if' condition "allows control to be applied to "an arbitrary fragment" of the host language.
This is not true.  Wrapping a content range in the host language in an 'if' element must preserve well-formedness.  The 'if' may
not start in the interior of one host language element and extend into the interior of a different element.   There are much more
general text ranges that can be selected with XPath than the set of fragments legal to wrap in a 'sel:if.'  The term 'arbitrary fragment' should be reserved for classees of text ranges that are more general than what is true here.

"body content" is non-standard terminology

Please compare with XML specification and CSS .content property.  Use standard terms for standard XML ideas.

Exception handling

The wording in this section is IMHO non-standard and should be regularized.  The following terms are suggested:

The nouns in the <dl> explanation of the categories *must* be aligned with the suffixes used in the event names.  Also the prose in the paragraphs.  In the current prose there are two concepts used (failure and error in the above lexicon) and three ways that each is alluded to.  Fix it.