- From: <bugzilla@jessica.w3.org>
- Date: Wed, 12 May 2010 18:15:58 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9715 Jim Melton <jim.melton@acm.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |jim.melton@acm.org Component|XSLT 2.1 |XPath 2.1 AssignedTo|mike@saxonica.com |jonathan.robie@redhat.com --- Comment #3 from Jim Melton <jim.melton@acm.org> 2010-05-12 18:15:57 --- David, thanks for opening (yet another) discussion on this subject. I've taken the liberty of re-characaterizing this Bugzilla entry against XPath 2.1, since it is (in some ways) the primary spec that links XSLT 1.0, XSLT 2.x, XQuery 1.x, and our other specs together. I've also reassigned the bug to myself. Before I say anything else, I want to reassure you and everybody else who reads this bug that the issue is well-known in the XSL and XML Query WGs, that is has been discussed on several occasions, and that none of us really believe that the issue has been resolved. But, as both Jonathan Robie and Mike Kay indicated in their comments, there are many factors to consider, not the least of which is the tradeoff in WG time spent debating version numbering versus fixing technical bugs and adding/refining new features. Sharon Adler (Chair of the XSL WG) and I (Chair of the XML Query WG) have just now spoken about this bug and several other events related to the same subject, and I agreed to write a comment for the bug. Most of the content of this response reflects our shared opinion, so I'll indicate clearly where I say something that is my separate, personal opinion. I want to correct something that Jonathan said: The version numbers of W3C specs is not something that the Chairs of WGs decide. Although the Chairs may have strongly-held views on the subject, we have used and will continue to use the consensus process to make such decisions. A consensus among the relevant (XSL and XML Query) Working Groups' participants and the responsible W3C Team/Staff members is the appropriate mechanism, which Sharon and I are committed to use. I agree with the premise that having a common version number among the various closely-related specs is desirable. I (personally) am not convinced that "3.0" is the best choice, but I wouldn't stand in the way of a consensus on that value. Here are some values that have been discussed, along with (what I believe is a fairly reasonable) brief summary of the pros and cons of each: * Leave the values as they are now -- Pros: the values are already known and in wide use in discussions, there are published documents using those values, and the entire infrastructure of development, editing, and maintenance is built around those values. Cons: having different values for documents that are essentially bound together is confusing, especially to the vast majority of users who are not part of the development process. * Change all documents' version numbers to "2.1" -- Pros: the values for XQuery and the "supporting" documents (e.g., Data Model, Functions & Operators, Serialization) will align with XPath and XSLT, and the increment from "2.0" to "2.1" reasonably reflects the relatively small increase in functionality. Cons: the level of functionality probably increased more than a ".1" version number suggests; end users may be confused about why XPath and XSLT version numbers aren't changes, while the other documents' version numbers were; significant work will be required in the development system where the documents are edited and generated. * Change all documents' version numbers to "3.0" -- Pros: changing all document numbers at once sends a clear signal that something significant happened, so consumers will take notice; the "major version number" change signals that there are significant changes/improvements in the specs. Cons: "What happened to XQuery 2.0?" is the question we'll be answering for years to come; significant work will be required in the development system where the documents are edited and generated. * Change the entire scheme to use a date-based scheme -- Pros: this has been used by other standards (e.g., SQL:1999, SQL:2003, SQL:2008); it avoids having to decide whether the first version of a new spec in the collection (e.g., XQuery Scripting Extension) should be numbered "1.0" or (e.g.) "3.0". Cons: the W3C has no history of date-based version numbering; it's not easy to predict the year when a complex set of specs will reach Recommendation; significant work will be required in the development system where the documents are edited and generated. As you can see from that limited summary above, the decision isn't easy to make, nor is the best answer immediately obvious. In joint teleconferences of the XML Query WG and the XSL WG (with admittedly limited attendance by XSL WG participants), there was not an absolute consensus to make a version numbering change at all (and, to be honest, the Chairs are unenthusiastic about doing so), and there was absolutely no consensus on what to select if a change were to be made. However, there will be a Joint Face-to-Face Meeting of the two WGs in mid-July, and this subject will be on the agenda of that F2F meeting. I cannot promise that we'll reach a consensus to make a change or to select a specific value for a change, but I assure you that we will try. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 12 May 2010 18:16:00 UTC