Edit comment LC-1777 for Device Independence Working Group

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

Comment LC-1777

Comment Shortname:

Commenter: Jim Melton <jim.melton@acm.org>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeAbstract Status of this Document Table of Contents 1 Introduction 1.1 Towards a Device Independent Markup Language Profile 1.2 Reading the Specification 1.2.1 Conformance Information for DISelect 1.2.1.1 Normative and Informative Parts 1.2.1.2 Normative Language for Conformance Requirements 1.2.1.3 DISelect Profiles 1.2.1.4 Document Conformance 1.2.1.5 DISelect Implementation Conformance 1.3 Documentation Conventions 2 Document Structure 2.1 The Namespaces 2.2 The Selection Module 3 Processing Model 3.1 Events Overview 3.2 Events in Response to Errors Exception Error 3.2.1 The diselect-invalid-type-error Event 3.2.2 The diselect-redeclaration-error Event 3.2.3 The diselect-declaration-exception Event 3.2.4 The diselect-compute-exception Event 4 Attributes for Conditional Processing 4.1 Overview 4.2 The expr Attribute 4.3 The selid and selidname Attributes 4.3.1 Generated Host Language Identifiers 4.4 The functions Attribute 4.5 Using the Attributes 5 Elements for Conditional Processing 5.1 Overview 5.2 Conditional Processing 5.2.1 The if Element 5.2.1.1 Attributes 5.2.2 The select Element 5.2.2.1 Attributes 5.2.2.2 Processing 5.2.3 The when Element 5.2.3.1 Attributes 5.2.4 The otherwise Element 5.2.4.1 Attributes 5.3 Using the Elements 6 Variables 6.1 The variable Element 6.1.1 Attributes 6.1.2 Declaring a Variable 6.1.3 Referencing an Existing Variable Using the variable Element 6.1.4 References to Variables in XPath Expressions 6.1.5 Scope of Variables and Nesting 6.1.6 Types string number boolean 6.1.6.1 Type Conversion 6.2 The value Element 6.2.1 Attributes 6.3 Using Variables 7 Attribute Value Templates 7.1 Using Attribute Value Templates 8 XPath Expressions 8.1 Identifying Profiles and Versions 8.1.1 The getProfileName function 8.1.1.1 Prototype 8.1.1.2 Function 8.1.2 The sel:getVersion function 8.1.2.1 Prototype 8.1.2.2 Function 8.2 DISelect Basic XPath Support 8.2.1 Accessing the Delivery Context using the XPath Subset 8.2.2 Formal Grammar for the DISelect Basic Subset 8.3 DISelect Full XPath Support 8.3.1 Path-Based Access to the Delivery Context 8.3.2 Path-Based Access to the Host Document 8.4 Extension Functions A Schema B References B.1 Normative References B.2 Informative References C Changelog (Non-Normative) C.1 Changes in this Version D Acknowledgements (Non-Normative)
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

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.

Related issues: (space separated ids)

WG Notes:

Resolution: 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

(Please make sure the resolution is adapted for public consumption)