This is the list of issues related to the last call working draft of Content Selection for Device Independence http://www.w3.org/TR/2005/WD-cselection-20050502/
This is the status
Color key: error warning note
| Id: Title | State | Type | Ack. |
|---|---|---|---|
| WAI-1 : Scope of expressions | agreed | clarification | No reply from reviewer |
| WAI-2 : Model best practice in examples | agreed | clarification | No reply from reviewer |
| froumentin-2 : typos in spec | agreed | editorial | No reply from reviewer |
| froumentin-3 : section 5 reorganisation | agreed | editorial | No reply from reviewer |
| Harold-1 : Violation of separation of content from presentation | agreed | error | No reply from reviewer |
| Gilman-11 : Must use namespaces | agreed | error | No reply from reviewer |
| Gilman-12 : Importing Attribute Value Templates | agreed | error | No reply from reviewer |
| Gilman-13 : Delivery Context Namespace | agreed | error | No reply from reviewer |
| Gilman-14 : content of the if element | agreed | error | No reply from reviewer |
| Gilman-15 : body content is non-standard terminology | agreed | error | No reply from reviewer |
| Gilman-17 : Exception handling part 2 | agreed | error | No reply from reviewer |
| HTML-1 : Violation of separation of content from presentation | agreed | error | No reply from reviewer |
| Gilman-3 : Interactive option | agreed | proposal | No reply from reviewer |
| Gilman-4 : CSS Class Terminology | agreed | proposal | No reply from reviewer |
| Gilman-10 : process=once | agreed | proposal | No reply from reviewer |
| Sathish-1 : minor editorial comments | agreed | clarification | Agreement |
| McCathieNevile-3 : Default id attribute | agreed | clarification | Agreement |
| froumentin-1 : make function xpath2 compatible | agreed | proposal | Agreement |
| McCathieNevile-1 : Window Size | declined | clarification | No reply from reviewer |
| McCathieNevile-2 : Minimum Font Size | declined | clarification | No reply from reviewer |
| McCathieNevile-4 : Screen resolution units | declined | clarification | No reply from reviewer |
| McCathieNevile-5 : Author control of re-rendering | declined | clarification | No reply from reviewer |
| Seeman-1 : Cannot apply DISelect to a doc that doesn't contain DISelect | declined | editorial | No reply from reviewer |
| Harold-2 : Use of < and > in XML based language is confusing | declined | error | No reply from reviewer |
| Gilman-2 : User overriding author's precept | declined | error | No reply from reviewer |
| Gilman-16 : Exception handling part 1 | declined | error | No reply from reviewer |
| Gilman-1 : Author proposes, user disposes | declined | proposal | No reply from reviewer |
| Gilman-5 : Append to class, don't replace it | declined | proposal | No reply from reviewer |
| Gilman-6 : Scope of expressions | declined | proposal | No reply from reviewer |
| Gilman-8 : The 'em' length unit | declined | proposal | No reply from reviewer |
| Gilman-9 : Inconsistent show/hide policy | declined | proposal | No reply from reviewer |
| Gilman-7 : How to get this across | declined | request | No reply from reviewer |
| McCathieNevile-6 : Link to Table of Contents | declined | editorial | Objection |
1. Please confirm that the full delivery context information space, and properties of entities in the current host-language document can be used inside the guard expressions that provide the values of 'expr' and 'when' attributes.
In summary, DIWG agrees with this comment. The following response indicates the changes we plan to make. We'll respond more fully with details of the actual changes once they have been determined.
XPath expressions within the expr attribute can use any information available to the processor. The specification explicitly discusses extensions by way of additional XPath functions and provides the means by which authors can check for the availability of the functions on which their expressions may depend.
However, the specification only explicitly discusses a 'starter set' of functions which mimick the capabilities of the proposed CSS Media Queries specification. It is certainly not the intention of DIWG to imply that this is the only set of functions that can be used. We recognise that the current structure of the document can lead to this impression, which is certainly not what we intend. To try and address this, DIWG intends to split the definition of functions into a separate document. At the same time, we will define additional functions which broaden the capability of the specifications. We recognise that this will entail a second last call for the specification.
The point about access to the host language document is interesting and is an example of a more general case for access to materials other those within the delivery context itself. The comment exposes the potential need for a way to identify the particular XML document to which an expression or part of an expression applies. DIWG will define functions that make explicit which XML document is being referenced by expressions. These capabilities will be modelled on those used to identify model instances in XForms. The functions will be described in the new document that defines specific XPath functions.
Further, we note suggestions, in a related comment (Gilman-6), about possible sources of content that could be used in examples to accompany description of access to items in the host document.
2. Please write the examples to model best practice.
In particular:
When setting 'class' attributes, set semantic values, not presentation-effect-soundalike values [1]. Use Attribute Value Templates to insert tokens into the list in the 'class' attribute value, don't set the value and obliterate pre-existing information.
Examples should favor using content properties in these expressions rather than just literal thresholds compared with delivery context properties. The 'metadata for content adaptation' workshop [2] may suggest common and educative examples of content properties to touch on. Also the IMS Accessibility Profile [3].
Exemplify the full visibility of the expression space; do not only or over-use the convenience functions.
Some examples should use delivery-context properties that reflect user preferences or settings as opposed to just hardware properties. See the IMS profile for good choices.
In summary, DIWG agrees with this comment. The following response indicates the changes we plan to make. We'll respond more fully with details of the actual changes once they have been determined.
The example in section 7.1 is valid from a device independence standpoint. We need to retain it because it is relevant and represents and example of the simplest kind of use case. However, we will add examples that illustrate the additional use case of adding to a list of classes. We would point out that changing a class name in itself does not necessarily militate against good accessibility practice. An author might do that explicitly in order to provide a better overall experience for people with, for example, lower visual acuity.
The selection of the particular names for the classes in the example is unfortunate. It is certainly not meant to indicate the content of the CSS. This is the case which Tantek Celic correctly argues against in the cited paper. The names were meant to indicate that the author considered this to be a class suitable for use on a device with certain types of capability. In this particular case, grey referred to the device capability not the content of the stylesheet. In any case, we will clarify this and will use names less open to misinterpretation.
In addition, to the explicit changes in the current document we are preparing a primer document that will provide more extensive examples of the use of DISelect.
There are many typos in the spec, mostly missing spaces following code or anchor tag.
Section 5 is confusing because one doesn't know the structure of each element until 5.10. I would suggest examples in each section. Or even better, something like:
5.1 Overview
5.2 Conditional Processing
5.2.1 if
5.2.2 select (describe when/otherwise here)
5.3 Options
5.3.1 idreplace
5.3.2 process
5.3.3 required
The primary issue is that the internal structure of the <select> element is not apparent at the start of section 5. While we accept that there can be an improvement here but recognise that we need to ensure that all of the elements be defined in sections that appear at the same nesting level in the TOC to make them easy to spot.
We have reorganised the section along the lines described in the comment.
This is a formal last call comment to which I request a response from the working group during disposition of comments.
It seems to me that the design of Content Selection for Device Independence massively violates section 4.3 of the Architecture of the World Wide Web, "Separation of Content, Presentation, and Interaction". It is inappropriate to place the rules for specifying which devices should display which parts of a document in the document itself.
I have no objection to writing stylesheets that tailor the display of content to particular device profiles. However, it should be presented as a separate document, not as a part of the original document. Possibly a new stylesheet language is needed to enable this.
Among other problems, the current approach will cause troubles for non-CSDI aware processors which will see additional markup in the document they are not prepared to handle, and which may hide and obscure the markup they expect. It also makes the documents harder to generate, and requires document authors to concern themselves with both content and presentation when the document is first created. It mean that schema will need to be adjusted to support this markup. I could go on. I am frankly astonished to see at this late date a W3C working group effectively ignoring the well-known principle of separating content from presentation.
Codi is a spec for describing how and indeed whether content should be presented on particular devices. Separation of presentation from content mandates that the Codi information not be mixed with the documents it describes.
DIWG has long recognised the importance of the separation of content and presentation. The group's views on the requirements for device independence are documented in http://www.w3.org/TR/acdi/. A number of the group's members have significant, practical experience of large-scale implementations of device independent authoring systems that themselves provide separation of concerns.
DIWG is engaged in creation of a number of related techniques that aid authors in creating device independent materials. The individual items are documented in our charter at http://www.w3.org/2004/05/di-charter-2004-06.html.
In particular, in the authoring space, we are pursuing work on physical layout of material, semantic enrichment, and mechanisms for aggregation and decomposition. The work is focused on creating modules that can be added to XHTML Version 2 and XForms, to enhance those specifications for situations where authors require to create materials that can be used across a variety of devices. However, the group is also engaged in work to extend CSS to support, for example, mechanisms for page layout that are independent of the page markup.
DISelect (our preferred acronym for the content selection work) forms just a part of this overall profile.
It is the group's intent that DISelect be available to authors writing in, for example, XHTML 2, but it is not the intent that such markup be restricted to that use. Consider the task of providing different versions of an image for different devices. This is a common requirement in situations where transcoding alone gives inappropriate results. In this situation, a markup that defines a set of images to be used under different conditions could be formed of a host language that includes DISelect as a module. A reference to an image from an XHTML 2 object element might be resolved by a processor that made the appropriate selection between alternative representations using DISelect. In this case, the DISelect markup would not be in the document containing the XHTML 2 markup itself. Indeed it might not even be in the same system.
In a similar example, DISelect might be used only to control the inclusion of materials from different sources, for example using XInclude. Once again, there is the possibility of a clear separation of concerns.
Sometimes, content selection is required even where the content is itself device independent and the reason for using it is not really associated with presentation but rather the semantics of the operation. A simple example is when the abstract for a news article is sent to a device rather than the full text of the article. The most convenient way to arrange this may be for there to be a separate resource for the abstract and for the article and for contnent selection to be used to determin which is sent. Again, in this example, there is no need for the selection markup to be in the same resource as either of the forms of the article.
Experience with practical implementations indicates that there is a real need for content selection to be available in a variety of ways to support authors in creation of materials that can be used on a variety of devices.
As with most things, though, such capabilities are open to misuse.
DIWG agrees with this comment to the extent that we believe it reflects a lack of clarity in some of the description. DIWG had hoped that its work on its language profile would be sufficiently advanced to allow it to be referenced from the DISelect specification. Unfortunately, that has not proved to be the case, and the working draft of that work is not yet public. In the absence of that document, we propose to:
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.
We do not intend to provide any mechanism to allow the inclusion of DISelect within other language's namespaces.
However, we agree with the point made in this comment that the wording is unclear. We have expanded the description in the section entitled 'The Namespaces' to make our intentions clear
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?
This is a typographical error in the current last call document. The namespace was introduced to allow the use of QNames on XPath functions used in expressions. Due to a subsequent misunderstanding of the XPath specifications, (an issue we are dealing with under Froumentin-1) we removed the use of QNames for functions but I omitted to remove the corresponding namespace. However, as a result of the likely resolution to Froumentin-1, we will reintroduce this, or an equivalent, namespace along with the use of QNames for XPath functions that can be used in DISelect expressions.
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.
We agree that this is an inappropriate use of the term arbitrary and implies more than we had intended. We will use more appropriate wording such as "The if element allows control to be applied to a wider range of xml document fragments than does the expr attribute alone."
Please compare with XML specification and CSS .content property. Use standard terms for standard XML ideas.
We agree and will use more suitable and more standard wording. New wording says:
The DISelect processor evaluates the expression. If the result has a boolean value of true, the element and all of its descendents appear in the result infoset. If it has a value of false, the element and its descendents are omitted from the result infoset. The attribute itself does not appear in the result infoset.
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.
We agree and have corrected the typographical errors. We use the terms error and exception consistently throughout the document. Other changes in this area of the document are anticipated in order to address Gilman-10 and McCathieNevile-5.
1) It takes us back to the bad days of mixing content with presentation details. 2) The selection mechanism is reminiscent of the C #ifdef style of content selection, which has proven to be difficult to manage, and results in a spaghetti code that has to be tested on all combinations of platform before you can be reasonably sure that it is correctly organised.
DIWG agrees with the HTML group that mixing styling and content is generally undesirable, and it is not our intent to promote such practices. Just because something is possible does not make it desirable. XHTML, through the style attribute, makes mixing of style and content possible. That doesn' t automatically mean that such usage should be encouraged.
It is certainly not DIWG' s intent to promote DISelect as an alternative to existing styling methods. Indeed, we would anticipate it being used, for example, to allow fine control over which of a number of CSS stylesheets might be used for different devices. Selection itself might take place completely external to the document containing the content.
These more realistic uses of DISelect are difficult to use when trying to describe and illustrate the basic syntax. DIWG believes that the best way to encourage good practice in the use of DISelect is to publish a primer alongside the formal specification. Work on this document has begun and publication will occur sometime after that of the formal specification.
DIWG expects to issue a second last call for the DISelect specification shortly. There have been a significant number of modifications.
By the way, the DIWG' s experience of developing sites that can be used by a multitude of different kinds of device shows categorically that while it is possible to use XSLT and CSS to create different versions, it is impractical to do so. Modern mobile systems, for example, avoid direct use of XSLT for adaptation, though they do use it in other roles. Such systems must cope with thousands of different kinds of device.
In summary, we will not make any specific modifications to the DISelect specification in response to this comment, but we will introduce a primer to assist readers in understanding how DISelect can be used in practice.
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.
DIWG agrees with this comment to the extent that it illustrates the need for functions to be able to update the delivery context.
CC/PP is the transport mechanism for delivery context and should form the basis for its transmission. DIWG does not believe that developing an alternative mechanism is appropriate. However, DIWG recognises that the storage of delivery context is a matter of implementation for any system that supports it, be it client or server based.
DIWG will address the specification of at least one function capable of updating delivery context within the new XPath function document it proposes to create.
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.
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.
The ability to suppress rerendering is really important for usability. If many events on a device, for example, could force the page to be rerendered, the device might spend a significant amount of time rerendering between user operations. We need to allow authors to be in a position to control when rerendering occurs to avoid this kind of usability issue.
In discussing this comment, and the related McCathieNevile-5, we have realised that there are deficiencies, in the level of control, that need to be addressed. Specifically, we expect to remove the <process> element and provide control of reprocessing via improvements in the event model. An author would need to capture the reprocess event explicitly in order to prevent reprocessing.
Here are some minor editorial comments:
1. Section 4.3 The selid and selidName Attributes
Last line in that section "Section 4.4 Using the Attributes illustrates the use of the expr attribute" I guess you mean "Section 4.4 Using the Attributes illustrates the use of the selid and selidName attribute" 2. Section 5.3.1 Attributes For precept attribute. It would be good to add a line that says: "It can take one of the following values: " that can avoid confusion. It has been done for section 5.8.1.
3. Section 5.10 using the elements. In the last example that shows the use of Options and select, within the first "when" element, you probably need to escape the "and" with &
4.Section 3.2.1 diselect-reprocess Event.
Can you be a bit more specific about how the event will be handled? for example use XML events? An example would help (something like <sel:process type="every" ev:event="diselect-reprocess" ev:handler="http://uri/to#handler"/>)
We have changes the relevant parts of the document to address the errors noted in this comment. For all the comments we have modified the text as specified in the comment. For the clarification, we have ammended the description of the way in which teh diselect-reprocess event is raised external to the processor.
3. Section 4.3 discusses the use of selid as an attribute that allows you to specify something which will turn into an ID in the result document - repeating it for several alternative pieces of content. When this is converted, the spec requires a default attribute name to be specified. It seems more sensible to default to xml:id. Instead the specification talks of a language profile that "somehow" defines the attribute that this should become, but does not appear to specify anywhere how this actually occurs or what such a profile looks like. As an alternative to xml:id as a default, it would seem important to clearly specify how such a profile is constructed
This is an excellent suggestion and we have incorporated it. We have changed the description associated with the selid and selidName attributes accordingly. We have retained the ability for a language profile to specify a default id name of other than xml:id and have provided a reference to the way in which this can be achieved via the idreplace element.
The functions could be defined in the same style as the XPath2/XQuery Functions and Operators spec [2], i.e. make them namespaced? "di-cssmq-width" -> "sel:cssmq-width". That would allow XPath2 engines to use the functions without any ambiguity about where they come from.
1. The spec allows you to ask questions about the size of the window, and about the display size (resolution and colours) of the entire device. This seems of limited use except in allowing authors to determine a layout for the fullscreen and then if there is a difference just put in a message like "move to fullscreen to get the page". This seems to me a bad thing to encourage. I am wondering if there are things that make it more useful? (The only one I could think of was knowing that if the user is at fullscreen they don't see other windows, etc... I am not sure if this should be exposed to authors...)
2. There is no clear way in the spec of finding out the user's font size. Most modern browsers have implemented a minimum font size setting, because users wanted it. Finding out what that is would be extremely helpful for authors, whereas just giving them the pixel size of the screen forces them to make guesses about the font size being used.
The particular functions described in the document are equivalents of those proposed for CSS Media Queries. We have deliberately retained exactly the same function as is used in that specification. There is no function currently in CSS MQ for font size determination.
It is worth noting that the set of functions is described in the specification as a starter set. Extensions that provide additional XPath functions are explicitly allowed and authors are supported in using them. Because other comments have indicated that this may not be clear from the document, DIWG is restructuring the document into two. One deals with the markup and expressions independent from the functions, and the other describes the set of functions.
4. Section 9.12.2 describes the function of a test for resolution, but simply says that it is a decimal number. It should give units, which apparently (from the explanation in an example, explicitly marked informative) are intended to be dpi.
Because of the general difficulty of returning multiple values from function and method invocation, DIWG has adopted a different approach in its XPath functions. The units in which a value is required is an input parameter. You can see this in the function protptype in section 9.12.1. The units parameter is a string in which the author must define the units in which the value is to be returned. In the example you cite, the author has supplied the value dpi which is one of the standard units recognised by CSS. We describe the use of these in section 9.15. It is a responsibility of the implementation of the function to verify that the units value is appropriate for the property being requested and to perform any conversion required. The value returned by the function is always the value of the property in the units specified in the call.
5. Section 5.8 allows the author to control re-rendering, by suppressing the ability to recalculate what content should be included. This seems like a bad idea, since while it can be used to allow an author to force a user into a particular font size, window configuration, etc, I don't see any positive effects for it.
The ability to suppress rerendering is really important for usability. If many events on a device, for example, could force the page to be rerendered, the device might spend all its time rerendering. We need to allow authors to be in a position to control when rerendering occurs.
Although we have to decline this comment as written, since control of rerendering is an important usability consideration, we are addressing improvements in the granularity of control of reprocessing via changes in the way that events are defined. We are addressing these changes in the response to Gilman-10.
DI Select does not require describing the content in order to adapt it to author specified scenarios.
This use case is not within the scope of those against which DISelect was developed. However, combinations of technologies such as XInclude together with DISelect might provide a solution.
Future work planned by DIWG on semantic enrichment might provide an appropriate environment in which to pursue the notion of combination of DISelect with annotation metadata in providing solutions for such use cases.
We will add some text in an appropriate overview section to clarify the scope and the fact that this markup is intended to be used within a larger set of modules that include markup capable of supporting semantic enrichment. By support of semantic enrichment we mean support of the XHTML 2 role attribute
The reserved characters should &, <, and > should not be used as operators in a language that appears in XML contexts. The double escaping this requires is hard to read and confusing. For instance, consider this:
<p sel:expr="di-cssmq-width('px') > 200 & di-cssmq-color() > 0">
<object src="image1" sel:selid="artimg42" sel:selidName="myns:myid"/>
</p>
Isn't this easier to understand?
<p sel:expr="di-cssmq-width('px') GT 200 AND di-cssmq-color() GT 0">
<object src="image1" sel:selid="artimg42" sel:selidName="myns:myid"/>
</p>
I'm not sure AND, GT, and LT are necessarily the best alternatives to &, <, and >. That can be discussed. However we know from experience with XSLT and most especially URL query strings that using these three characters in attribute values confuses users and makes the langauge harder to learn and harder to use. Let's not repeat the mistakes of the past.
There's no need to overload reserved characters like this.
While DIWG agrees that the syntax of XPath expressions used within XML documents is less than elegant, it is mandated by XPath. Where XPath is used within an XML document, such as XSLT or DISelect, escaping is mandated. There is a note to this effect in the discussion of Booleans in the XPath specification (see http://www.w3.org/TR/xpath#booleans).
XPath is already widely used within W3C specifications and creation of an entirely new syntax just for DISelect would be inappropriate. DISelect is also intended for use with other specifications, such as XForms, which also use XPath expressions. In such mixed environments, consistency is a key factor.
DIWG has decided to retain the use of XPath and hence the need for escaping.
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 reasons why it is not possible in general to allow content simply to flow to the UA for user choice have already been discussed in the response to Gilman-1. Alternative mechanisms to provide better means of influencing user experience have also been addressed there.
This comment does raise the issue of distribution of adaptation and the protocols required to allow one DISelect processor to inform another of its capabilities. This protocol is considered outside the scope of the DISelect specification itself.
The wording in this section is IMHO non-standard and should be regularized. The following terms are suggested:
The exception handling model and terminology is meant to be completely consistent with that of XForms. For reasons of consistency, DIWG has chosen to retain that terminology. However there are typographic errors in this section which we will address in Gilman-17.
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:
There is a tension between the aims of UAAG10, of those that wish to protect some groups of users from inappropriate content,(reference to the metadata workshop in Dublin) and the physical capabilities of devices. DISelect needs to take account of all of the reasons why content selection may be needed and hence must have capabilities that might not conform to the needs of any one in particular.
Considering first the case of device capabilities, there are many examples today of situations in which it is impossible to send material to allow user selection. There are well known situations in which sending material intended for a different device, perhaps using an entirely different markup language, will cause it to crash. Worse, there are known cases where inappropriate content can damage the device to the point where it needs to be returned to the manufacturer. Although such situations should improve in future, one aim of DISelect is to support the currently available range of devices, so considerations like this are of great importance.
In the case of inappropriate conent, there are groups who need to ensure that, for example, adult material is not sent to devices being used by minors. Any scheme that only supports user selection of content at the device cannot be used as part of a system that supports such use cases.
DIWG is sympathetic to the aims of UAAG10, but feels that it would be inappropriate to try and use DISelect to enforce appropriate author behaviour. We suggest that a better solution would be to expand WCAG to cover appropriate use of DISelect to support accessibility.
DIWG also suggests that guidelines like UAAG10, while appropriate for current and legacy technologies, lack some ambition in environments where better semantic information, better information about user preferences and distributed adaptation can truely tailor user experience for a much wider variety of users. It should surely not be the case that simply because someone has a disability that they are forced manually to tailor their user experience? DIWG would like to see the possibilities of adaptation together with proactive involvement from assistive technologies, provide an environment in which the vast majority of users with or without disabilities can be served without having them having to intervene manually.
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.
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.
DIWG believes this is the same issue as WAI-1 and we deal with it under that identifier. We do note the suggestions about sources of content for use in examples. Declining this comment does not imply that we do not accept it, merely that we believe it to duplicate another comment.
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.
DIWG agrees that access to metrics based on font size is desirable. However, the starter set functions merely replicate the capabilities of CSS Media Queries as currently defined. Since that is their declared purpose, it would be inconsistent to extend them.
However, as is noted in the response to comment WAI-1, DIWG will expand the set of XPath functions to include more general mechanisms for access. Such functions would be capable of retrieving font-size based information if that is available in the delivery context.
So, while DIWG declines to extend the starter set functions, we believe that other facilites will make this information available to authors if it is available within the delivery context.
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.
This issue is similar to Gilman-1. The problem we face is that an unrecoverable error in expression processing yields completely unpredicatble results, including XML that is invalid or badly formed. Allowing processing to continue could lead to effects similar to those we outlined in Gilman-1, including crashing or damaging the user's device, or showing completely inappropriate material to a minor.
In contrast, the default value of the expr attribute is specified so the behaviour obtained by omitting it is at least predictable.
In addition, by providing a default value, we ensure backwards compatibility when DISelect is added to a processor which processes existing markup written before the DISelect module was added.
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.
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.
DIWG agrees that discussion on this topic, perhaps in the context of an expanded set of best practices for WCAG or MWIBP would be useful. In the interests of completeness of responses, we are recording and declining this comment not because we disagreee, but because we believe this is outside the scope of DISelect. We will follow up in a different forum.
6. Navigating the specification document would have been easier with at least a link element to its table of contents
DIWG has sympathy with this comment. We are, however, constrained, to some degree, by the W3C tools that we have chosen to use to create the specification. We will improve the navigation by preparing a version of the specification as a set of HTML files, in addition to the single HTML file version. To this extent, we accept the comment.
The WG accept the formal objection to be reported to the director.
Last update: $Date: 2006/10/06 12:43:31 $
This page was generated as part of the Extensible Issue Tracking System (ExIT)
Copyright © 2003, 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.