Disposition of comments for the Device Independence Working Group

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.

http://lists.w3.org/Archives/Member/w3c-wai-pf/2006OctDec/0027.html

The discussion in CSS came from users of forms in mobile devices, not
originally
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]

Al

At 11:15 AM +0000 1/4/06, Roland Merrick wrote:
>Greetings Al, thanks for your comments on the content selection last
>call [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.
>
>[1]
>http://lists.w3.org/Archives/Public/public-diselect-editors/2005AprJun/0012.html
>
>Regards, Roland

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.

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:
<quote
cite="http://www.w3.org/TR/2006/WD-aria-state-20060926/">

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].

</quote>

.. in the specification section:
<quote
cite="http://www.w3.org/TR/2006/WD-aria-state-20060926/#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.

<snip/>

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.

</quote>

Al

At 11:30 AM +0000 1/4/06, Roland Merrick wrote:
>Greetings Al, thanks for your comments on the content selection last
>call [1]. 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.
>
>[1]
>http://lists.w3.org/Archives/Public/public-diselect-editors/2005AprJun/0012.html
>
>Regards, Roland

[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.:

<quote
cite="http://www.w3.org/TR/2006/WD-cselection-20061010/#id2271490">
This variable holds the name of the CSS style class used to provide
styling definitions for the user experience.
</quote>

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.

Al


At 11:15 AM +0000 1/4/06, Roland Merrick wrote:
>Greetings Al, thanks for your comments on the content selection last
>call [1]. As part of this you include
>"<http://www.w3.org/TR/2005/WD-cselection-20050502/#error-events>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.
>
>[1]
>http://lists.w3.org/Archives/Public/public-diselect-editors/2005AprJun/0012.html
>
>Regards, Roland

References:

- Issues:
http://www.w3.org/TR/2006/WD-cselection-20061010/issues.html#Gilman-14

- Current 2nd Last Call draft:
http://www.w3.org/TR/2006/WD-cselection-20061010/#id2269811

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

The wording in the current draft

<quote
cite="http://www.w3.org/TR/2006/WD-cselection-20061010/#id2269892">
>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.
</quote>

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.

Al


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
>To
>public-diselect-editors@w3.org
>cc
>w3c-di-wg@w3.org
>Subject
>Gilman-14
>
>
>
>
>Greetings Al, thanks for your comments on the content selection last
>call [1]. As part of this you include "Content of
><http://www.w3.org/TR/2005/WD-cselection-20050502/#sec-sel-if-element>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
>alone."
>
>[1]
>http://lists.w3.org/Archives/Public/public-diselect-editors/2005AprJun/0012.html
>
>Regards, Roland

1. I am not satisfied with what the 'disposition of comments'
document says is the
disposition of this comment.

BUT

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

AND

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

SO

.. 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.]

Al

At 11:15 AM +0000 1/4/06, Roland Merrick wrote:
>Greetings Al, thanks for your comments on the content selection last
>call [1]. 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.
>
>[1]
>http://lists.w3.org/Archives/Public/public-diselect-editors/2005AprJun/0012.html
>
>Regards, Roland

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.]

Al

At 11:15 AM +0000 1/4/06, Roland Merrick wrote:
>Greetings Al, thanks for your comments on the content selection last
>call [1]. As part of this you include
>"<http://www.w3.org/TR/2005/WD-cselection-20050502/#error-events>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.
>
>[1]
>http://lists.w3.org/Archives/Public/public-diselect-editors/2005AprJun/0012.html
>
>Regards, Roland

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?

Also:

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.

== 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.

== Reference ==
I don't understand the dependency on XHTML 2 normatively ? Is this not
possible to use it with XHTML 1 ?

A lot of space are missing. It seems the XSLT Transformation has not
been done with helpful tools

http://"dcn:cssmq-device-aspect-ratio-height() = 9" is repeated twice in
different styles

Spellings are English not American