W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2010

[Bug 9715] Version Number

From: <bugzilla@jessica.w3.org>
Date: Wed, 12 May 2010 18:15:58 +0000
To: public-qt-comments@w3.org
Message-Id: <E1OCGTO-0008O9-Rr@jessica.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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:42 UTC