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
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.
>
>>
>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
|
yes |
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
specification.
Rhys Lewis |
yes |
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:
<quote
cite=" ARIA">
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=" 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.
<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. 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
|
yes |
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.:
<quote
cite=" cselection">
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. 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
|
yes |
LC-1572
Al Gilman |
References:
- 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
<quote
cite=" cselection">
>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. 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
>alone."
>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
|
yes |
LC-1573
Al Gilman |
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. 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
|
yes |
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.]
Al
At 11:15 AM +0000 1/4/06, Roland Merrick wrote:
>Greetings Al, thanks for your
comments on the content selection last
>call . 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
|
yes |
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?
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.
|
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
<
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
|
yes |
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
|
yes |
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
|
yes |
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
http://lists.w3.org/Archives/Public/public-diselect-editors/2007JanMar/0009.html
Disposition accepted
|
yes |
LC-1569
Innovimax SARL |
Spellings are English not American
|
Check for American spelling before next publication
Resolution communicated
to the commentor
Disposition accepted
|
yes |