This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
4.2.1 The support as described includes the schema components if the vc:minVersion <= actual version <= vc:maxVersion. That means 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 schemas. It seems perfectly valid to want to express the maxVersion semantic as "my schema component does NOT apply (should not be included) starting with version x.y". In 4.2.1's example, x.y=3.2. That way if someone creates a point release 3.15 after my 3.1 schema is out, I do not need to deploy any updates to that schema. Given the usual rules around breaking changes and versioning, my case would seem the more common one. Proposal: include the schema components if vc:minVersion <= version < vc:maxVersion (change maxVersion comparison from <= to strictly <).
>Proposal: include the schema components if vc:minVersion <= version < vc:maxVersion (change maxVersion comparison from <= to strictly <). I can see the logic, but then the attribute name would need to change. "maxExclusiveVersion" is pretty ugly (especially as the number is the first excluded version, not the last). Any suggestions? Personally, I'd be prepared to write maxVersion="1.999999". There's also the problem that in real life people want to use version numbers like 3.0.2. Perhaps we need a new datatype xs:deweyDecimal. In my view it has a much better right to exist than precisionDecimal... Michael Kay (personal comment)
This bug is from the SML workgroup as a whole, decided at 2007-10-25 telecon.
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 schemas. 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.
In comment #3 I claimed that specs with new version numbers are normally issued in numerical order (i.e. new version numbers higher than any existing one), so the presence of gaps in the number ranges doesn't much matter. John Arwe has pointed out that there are counterexamples, or specs which could easily have been counterexamples if they had been numbered 1.05 instead of 1.0 Nth edition. I acknowledge that my argument stinks.
WG decided to ask the editors to: 1) change the meaning of xs:maxVersion to be "max exclusive" 2) provide examples adequate to make that meaning clear.
At its telcon on 2008-02-15, the XML Schema WG adopted the wording proposal at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b5168.singleton.html (member-only link), and believes this issue now to be resolved. John, please let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.
mahvelous