W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2008

[Bug 5168] vc:maxVersion versioning

From: <bugzilla@wiggum.w3.org>
Date: Fri, 04 Jan 2008 01:59:47 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1JAbqd-0007Sd-0W@wiggum.w3.org>


cmsmcq@w3.org changed:

           What    |Removed                     |Added
             Status|NEW                         |ASSIGNED
  Status Whiteboard|                            |medium, work

------- Comment #3 from cmsmcq@w3.org  2008-01-04 01:59 -------
Speaking for myself, I agree with the proposition that for the
conditional inclusion mechanism described in the spec to work the
right way

  I have to know the full range of version numbers, including point
  releases, a priori in order to construct a continuous range of
  schema components.  Using the example in 4.2.1, if someone later
  does a point release of 3.1, e.g. 3.15, I have to update my

The proposed change does not, however, much appeal to me (partly for
the reasons given by Michael Kay in comment #1).  In reality, I
believe that in the large majority of cases, the schema author WILL
have the required knowledge of what versions of XSDL exist, and
which of them support the mechanisms used in the schema document.

The example given in section 4.2.1 imagines a world in which we have
a number of versions of XSDL, including 3.2 (explicitly mentioned in
the setup of the example) and 3.1 (implicitly suggested by the
comment in the example).  Under those conditions, I find it
implausible to imagine the production of a new version of the spec
with the number 3.15.  It's not forbidden, as far as I can tell, by
the existing notes on version numbering at W3C
(http://www.w3.org/2005/05/tr-versions), but I don't know of any W3C
spec whose version number has ever failed to be a value
monotonically increasing over time.

It is fair to say that the publication of a version 3.15, after 3.1
and 3.2 were already published, would put a strain on this
conditional inclusion mechanism.  That's one reason I think it
plausible to expect that any Working Groups responsible for XSDL in
the future will avoid doing such a thing.

Remember, the version numbers here relate to versions of XSDL, which
is a spec over which we and our successors have a certain amount of
control; the mechanism does not need to handle arbitrarily complex
version numbering schems, nor arbitrarily arbitrary ones.

By specifying this conditional inclusion mechanism as using decimal
values, we have effectively bound future WGs responsible for XSDL to
use decimal-valued version numbers (or break the mechanism). In a
similar way, I think the implication of the observations made in the
issue description is not so much that the condition inclusion
mechanism needs fixing, as that we have also bound future WGs not to
issue new versions of XSDL with numbers falling between two known
numbers, unless they know what they're doing and the benefits
outweigh the costs.
Received on Friday, 4 January 2008 01:59:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:07 UTC