Disposition of comments for the DISelect 1.0 and XPath Access Functions 1.0

In the table below, red is in the WG decision column indicates that no changes to the document were made based on the comment, and green indicates that a change was made to accommodate the comment.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

Commentor Comment Working Group decision Commentor reply
LC-1574 Al Gilman
I have to admit that discussions with CSS have shown that the 'em' unit is not
good for what we wanted to use it for: expressing the screen size in terms
of character count.

The suggestions from the CSS WG that we use a new constant that is defined
by the width of the zero character rather than the height of the
capital-em character
is supported by PFWG.
[Read the related Message]

The discussion in CSS came from users of forms in mobile devices, not
from disability issues.

So the DI framework needs to be able to incorporate this degree of freedom to
make its market opportunity. We need to find a way to accelerate the
insertion of this new unit in profiles that are actually getting used, in CSS,
in CSS Media Queries, and in DISelect.

With the substitution of the zero-width for the reference length unit, in place
of the capital-em-height, I still believe that responding to this
metric of display
size is an accessability requirement and lacking it is a defect in
the functions library.

[for the record: do not accept disposition]


At 11:15 AM +0000 1/4/06, Roland Merrick wrote:
>Greetings Al, thanks for your comments on the content selection last
[1]. As part of this you include "The 'em' length unit".
>The DIWG assigned this comment the identifier Gilman-8
>This mail documents DIWG's response to your comments.
>DIWG Response
>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.

>Regards, Roland
One possible mechanism to overcome this issue would be to extend the list of defined lengths in the XAF document, but subset it into absolute and relative and make the starter set functions have to return only the absolute lengths, with relative lengths optional. That would open the door to use of relative units without forcing it for initial implementations. That might even be considered an editorial solution rather than substantive.

However, it is more likely that WAI will require an actual implementation in which case the defaulting of font choice outlined in the notes (above) could provide a workable solution. If this value is important, it should be in the delivery context explicitly. This has implications for DDWG and the device ontology.

Note that in a subsequent side conversation Al indicated "Note that the 'ch' unit is not on a fast track in CSS so you can safely ignore it for now." That implies that we don't need to worry about that particular unit, not necessarily that we don't need to worry about relative units in general.

After a side conversation with Al, we agreed that it's ok to go forward with the DISelect spec as written, i.e. no relative units of measure. However, the need for relative units is real. It's in the ontology and should also be supported for preferences.

Resolution communicated to the Commentor

Al accepted the disposition
LC-1777 Jim Melton
I am concerned that these documents, especially Delivery Context: XPath Access Functions 1.0, reference and use the facilities only of XPath 1.0 instead of (only; or perhaps in addition to) XPath 2.0.

* The Ubiquitous Web Applications Working Group Charter seems to have been put into effect in October, 2006. At that time, the suite of specifications surrounding XPath 2.0 had reached CR and were transitioning to PR.

* According to that Charter, none of the WG's documents had achieved First Public Working Draft until June, 2004, at which time that suite of specifications had already entered Last Call (the first of two Last Call comment periods).

* The two specifications for which CR transition is being requested entered their Last Call comment periods in October, 2006 (coincident with the apparent effective date of the current Charter of the WG). Again, at that time, the suite of specifications surrounding XPath 2.0 had reached CR and were transitioning to PR.

It is not clear to me why documents being developed during the late stages of XPath 2.0 development and progression chose to use XPath 1.0 instead of XPath 2.0. I can accept the these two documents do not need the full functionality of XPath 2.0 (indeed, they apparently didn't need the full functionality of XPath 1.0, since they chose to subset even that language). However, the availability of (for example) a well-defined data model and of a rich library of functions would seem to have been of sufficient value to justify using (a subset of) XPath 2.0 instead.

It seems that, at one time (implied by Paul Cotton's comment) the documents did reference XPath 2.0, so a deliberate choice must have been made to delete that reference in favor of XPath 1.0.

I don't imagine that, once I have made the XML Query WG aware of the documents and my comments, there will be any sort of formal objection raised -- I certainly have no intent or desire to raise one! But I would, and it's possible that my WG would, appreciate hearing the justification for choosing to base your work on an obsolescent (although not obsolete!) language instead of the more carefully-designed second generation of that language.
Originally, DIWG tried to leave the door open for implementations based on
either XPath 1 or XPath 2. Paul Cotton's comments [1] showed us that this
was actually not feasible. The issue is the disjoint set of datatypes
covered by the two specifications. In particular, we did not want to
mandate the data types, to be used in expressions, in our specifications.
Yet XPath 2 requires us to do exactly that, as Paul pointed out.

Paul's comments left us with a dilemma. We would have to choose one
version of XPath on which to base DISelect.

One of the constraints on these specifications is that they could be
implemented on clients as well as servers. Although general, the
specifications are oriented towards enabling Web support for clients with
little processing power, battery power or memory. As a consequence, we
needed to be sensitive to the demands that the specifications might place
on implementations on, for example, mobile phones.

As you point out, we use only a subset of XPath 1.0 capability. There is
nothing in DISelect that requires any XPath 2 function. As you also point
out, XPath 2 is a considerable improvement over its predecessor, but it is
also much larger and more difficult to implement on small devices.

With the advice of the device manufacturers who were represented on the
DIWG at the time, we reluctantly concluded that since we could not leave
the door open to implementations on either XPath version, we would have to
pick one, and that the one we would have to pick would be XPath 1.

I hope that clarifies how we arrived at the current situation.

We think we examined all the options open to us that would have allowed
DISelect to be based on either version of XPath without requiring that
client side implementations support XPath 2. We couldn't find a way to do
that. If you can suggest a simple change to the wording of the
specifications that would open that door in a way that did not involve
normative changes, I would certainly welcome it.

Very best wishes and thanks again for your attention to the detail in our

Rhys Lewis
LC-1570 Al Gilman
I still have reservations about this disposition. While I don't
expect you to _provide_ profiles or mechanisms for integration of
this module into other namespaces,

a) there is something overweening about a module restricting its integrations.

b) namespace proliferation seems to be a big issue with the CDF WG.
If DISelect module technology is to be used client-side, and we hope
it will, we had better leave it to CDF and others to hammer out what
is going to happen to keep the namespace diversity down.

You don't have to _provide_ a mechanism other than namespacing this
vocabulary instance by instance, but you shouldn't sound as though
you are _precluding_ other modes of integration.

You might want to consider something like the language we are trying
in the States and Properties Module for Accessible Rich Internet
Applications (WAI-ARIA States and Properties)

.. in the Abstract:

This specification creates a language module implementing the
functional requirements of the abstract model that is ready for
incorporation in content format profiles that follow the methods of
XHTML Modularization [XHTMLMOD].


.. in the specification section:
cite="ARIA Module">

This specification defines the States and Properties module for XHTML
[XHTML]. It also defines a representative profile which extends the
XHTML 1.1 - Full profile by adding this module.


Section 3.1 below discusses examples of how the module may be
integrated into language profiles. Section 3.2 below then defines the
particulars of the module.



At 11:30 AM +0000 1/4/06, Roland Merrick wrote:
>Greetings Al, thanks for your comments on the content selection last
. As part of this you include "Must use namespaces".
>The DIWG assigned this comment the identifier Gilman-11
>This mail documents DIWG's response to your comments.
>DIWG Response
>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.
>Regards, Roland
Update the section on namespaces to make it clear that it is the intention to allow host languages to subsume DISelect into their own namespace. We should make it clear, however, that where such inclusion takes place, the expectation is that the function is identical to that in this spec. We should also make it clear that where the DISelect namespace is used it has the URI defined.

Resolution communicated to the commentor

Al accepted the disposition
LC-1571 Al Gilman
[disposition rejected; fresh comment/complaint lodged against the corresponding
text of the current draft.]

Note: This is an editorial, or expository comment; it does not bear
on conformance.

However, you misunderstood the comment in lumping it under WAI-2, and
the problem is still there in the current spec draft, viz.:

This variable holds the name of the CSS style class used to provide
styling definitions for the user experience.

This language is highly offensive.

The 'class' attribute, used right,

- *is* used to key styling decisions
- *is not* used to provide styling definitions

Styles and classes, used right, are not one-to-one.

In WAI-2 you did address the issue of "use content categories, not
styling categories as 'class' categories." Here it is not a question
of the terms the [host-language document instance] author uses in the
'class' attribute but the colloquial language used to misname the
'class' attribute. Just say " the 'class' attribute" and don't say
"the CSS style class" and this expository fault will be fixed. This terminology
is in the spec and you control it. The class tokens authors use
is on the other hand a matter out of your control.


At 11:15 AM +0000 1/4/06, Roland Merrick wrote:
>Greetings Al, thanks for your comments on the content selection last
. As part of this you include
>"Reword to eliminate "CSS class" terminology".
>The DIWG assigned this comment the identifier Gilman-4
>This mail documents DIWG's response to your comments.
>DIWG Response
>We agree that this is a valid comment, but we believe that it is the
>same issue as WAI-2 and we deal with it under that identifier.
>Declining it here does not imply that we do not accept the comment,
>merely that we believe it to duplicate another comment.
>Regards, Roland
Make the change throughout the documents.

Resolution communicated to the commentor

Al accepted the disposition
LC-1572 Al Gilman

- Issues
- Current 2nd Last Call draft:

Thank you for agreeing with my earlier comments. I think an
editorial glitch remains, however.

The wording in the current draft

>This mandatory attribute defines an expression used in determining
>whether or not the descendents of the element appear in the result
>infoset. If the expression evaluates to a boolean value of true, the
>descendents of the if element appear in the result infoset. If the
>expression evaluates to a value of false, the descendents of the if
>element are omitted from the result infoset.

does not seem to make it clear whether the 'expr' attribute itself
appears in the results
infoset. My impression is that you meant the answer to be 'no.' But
it didn't get into
this paragraph in the specification text.


At 5:07 PM +0000 11/17/05, Roland Merrick wrote:
>Greetings Al, my apologies, should have sent this to you and not
>just to diselect-editors list.
>Regards, Roland
>Tel/Fax: +44 (0)1926-465440
>Mobile: +44 (0)77 2520-0620
>----- Forwarded by Roland Merrick/UK/IBM on 17/11/2005 17:01 -----
>Roland Merrick/UK/IBM
>17/11/2005 14:44
>Greetings Al, thanks for your comments on the content selection last
. As part of this you include "Content of
>the 'if' Element" which starts with: "The specification prose says that
>an 'if' condition "allows control to be applied to "an arbitrary
>fragment" of the host language."
>The DIWG assigned this comment the identifier Gilman-14.
>This mail documents DIWG's response to your comments.
>DIWG Response
>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
>Regards, Roland
Update the description to make it clear that the elements and attributes do not themselves appear in the result infoset. Add links back to the processing model section.
2007-01-28 changes made

Resolution communicated to the commentor

Al accepted the changes and suggested some additional improvements in the text which were accepted
LC-1573 Al Gilman
1. I am not satisfied with what the 'disposition of comments'
document says is the
disposition of this comment.


2. It is a comment about the heuristic value of informative examples,
i.e. it does not
bear on conformance but on education,


3. The examples have been pulled and deferred to the Primer, where
there aren't any
to speak of yet.


.. for the disposition of this comment, please change to

"Overtaken by events" -- the examples in question have been moved to the Primer
and this issue may be discussed further in the evolution of that
document. Out of
scope here after the split into three documents.

[that disposition I would agree with.]


At 11:15 AM +0000 1/4/06, Roland Merrick wrote:
>Greetings Al, thanks for your comments on the content selection last
. As part of this you include "Append to class, don't
>replace it ".
>The DIWG assigned this comment the identifier Gilman-5
>This mail documents DIWG's response to your comments.
>DIWG Response
>DIWG believes this is the same issue as WAI-2 and we deal with it
>under that identifier. Declining it here does not imply that we do
>not accept the comment, merely that we believe it to duplicate
>another comment.
>Regards, Roland
Update the disposition in the first call comments in line with Al's request.

Resolution communicated to the commentor

Al accepted the disposition
LC-1575 Al Gilman
I don't understand the rationale offered.

Arbitrarily forcing the result of an 'expr' evaluation to 'true'
can't result in ill-formed XML if
the source was well-formed XML and conforms to the specification for
the module.

Getting garbage when a program runs amok is always possible, and
should be handled
as error control outside the scope of the DISelect module or its host
language. This
is in the OS, if I understand things right.

[reaction to the disposition of this comment: puzzlement.]


At 11:15 AM +0000 1/4/06, Roland Merrick wrote:
>Greetings Al, thanks for your comments on the content selection last
. As part of this you include
>"Inconsistent show/hide policy".
>The DIWG assigned this comment the identifier Gilman-9
>This mail documents DIWG's response to your comments.
>DIWG Response
>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.
>Regards, Roland
It seems as though the core of the issue is that the discussion of the default behavior, when expr is omitted, is still here. It should have been removed when we started work on DIAL. It is appropriate to discuss defaulting in the host language that contains DISelect, but not in the DISelect module itself.

2007-01-28 the offending paragraph has been removed. A comment about the default assumptions has been added to the section describing the examples in

Note that in a side conversation, Al indicated "Editor's comment -- pull the discussion and defer to the host language -- works for me."

Resolution communicated to the commentor

Al accepted the disposition
LC-1563 Elliotte Harold
There is a pervasive problem of missing spaces in the HTML version of the spec. For example, there's a space missing between functions and attribute in section 4.4:

"The value of the functionsattribute is a space-separated list of the
XPath extension functions that are required for processing. Each..."

A side note: the word functions is in code and the word attribute is
not. This is not the first time I've noticed this particular style of
missing space in a W3C draft. is it possible something in your toolchain is losing spaces after a </code> tag?


In section 1.1 I find this:

One common theme emerging from this work was the need to support authors
in the specification of variabilityin the materials they produce.

In this case there's a missing space between "variability" and "in".
Here a </a> tag separates them. It really is starting to look like a
weird tool bug.
Continue to use the alternate editor and to review the document for missing spaces after conversion. tocheck
LC-1565 Innovimax SARL
== Questions ==
Why are the XPath expressions given in examples XML escaped (with &lt;
for example) tough in XPath 1.0 specification the examples are not
escaped ?
I find it less readable and useless.
Remove the escaping in the examples in the XPath functions document and add a paragraph of explanation to the section on Documentation Conventions. Also add pointers to the DISelect specification and the primer for sources of examples of usage within DISelect.

Resolution eventually communicated to the commentor

Disposition accepted
LC-1566 Innovimax SARL
== Reference ==
I don't understand the dependency on XHTML 2 normatively ? Is this not
possible to use it with XHTML 1 ?
There is no dependency on XHTML 2 and it is not our intent that there should be a limitation in the host languages that can support DISelect. The offending paragraphs in the introduction are in error and should not be in this specification at all. Kudos to innovimax for spotting this error. We have removes the first two paragraphs from section 1.1. We have also remove the subtitle for section 1.1. The changes have been made in both the spec and the XAF document. In addition the informative reference to XHTML 2 has been removed from the XAF document since it is no longer necessary.
2007-01-26 change made in the 2007-01-31 versions of the documents.

Resolution communicated to the commentor

Disposition accepted
LC-1567 Innovimax SARL
A lot of space are missing. It seems the XSLT Transformation has not
been done with helpful tools
Same as 1563
Resolution communicated to the commentor

Disposition accepted
LC-1568 Innovimax SARL
http://"dcn:cssmq-device-aspect-ratio-height() = 9" is repeated twice in
different styles
Remove the incorrect second instance of the example. Kudos to innovimax for spotting this error.
2007-01-28 the change was made

Resolution communicated in

Disposition accepted
LC-1569 Innovimax SARL
Spellings are English not American
Check for American spelling before next publication

Resolution communicated to the commentor

Disposition accepted

Developed and maintained by Dominique Hazaƫl-Massieux (dom@w3.org).
$Id: diselect_doc.html,v 1.1 2007/07/16 13:49:44 boyera Exp $
Please send bug reports and request for enhancements to w3t-sys.org