This document:Public document·View comments·Disposition of Comments·
Nearby:Device Independence Working Group Other specs in this tool
Status: allopen proposal pending resolved_yes resolved_no resolved_partial other Type: allsubstantive editorial typo question general comment undefined
Quick access to LC-1563 LC-1565 LC-1566 LC-1567 LC-1568 LC-1569 LC-1570 LC-1571 LC-1572 LC-1573 LC-1574 LC-1575 LC-1777
There are 13 comments (sorted by their types, and the section they are about).
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
== 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
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.
[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
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 < for example) tough in XPath 1.0 specification the examples are not escaped ? I find it less readable and useless.
http://"dcn:cssmq-device-aspect-ratio-height() = 9" is repeated twice in different styles
Spellings are English not American
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
Add a comment.