Some comments on DISelect
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.
One revision of this technology that some might consider best for
access would be:
- There is no 'if' element or host-lanaguage 'expr' guarding
attribute. Only the 'options' element and an 'otherwise' clause
- The content of the 'otherwise' clause preserves all information
helpful for client-side profiling in a more general delivery-context
property space such as that given by the IMS Accessibility profile.
- All choices retain the hooks to interactively (think context
menu) inspect alternatives to the automatically-chosen branch in the
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.
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
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
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
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
'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
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
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
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.
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.
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?
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?
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.
content" is non-standard terminology
Please compare with XML specification and CSS .content property.
Use standard terms for standard XML ideas.
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.
- failure - replaces 'fatal error' (processor must fail the
processing transaction if this is raised)
- error - potentially recoverable error (processor may handle,
format may suggest how)
- warning - condition that the user may be expected not to have
- exception - any of the above