This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This issue was originally reported by the XML Schema WG. The XML Schema 1.1 specification must provide better support for the versioning and evolution of vocabularies defined by XML Schema, including XML Schema itself. More detailed elucidation of the goals to be achieved and the means of achieving them are a topic of ongoing work within the WG. The underlying issue applies to both Structures and Datatypes. This Bugzilla entry is for Structures.
The Working Group has made a number of changes seeking to provide better support for versioning schema-defined languages. Among the most obvious are: weakened wildcards, implicit wildcards, and negative wildcards. There are no versioning-related proposals currently outstanding, and so this issue has apparently served its purpose, as a mechanism for tracking our work. Accordingly, on 23 February the WG agreed to regard this issue as having been successfully resolved for XML Schema 1.1. Since the issue was raised by the Working Group itself, I report on behalf of the Working Group that we are happy with our resolution of the issue.
I'm reopening this issue in order that we can continue to use bug 2825 to track our versioning support -- at this point, the only further thing we expect to do w.r.t. versioning is to consider a proposal for versioning mechanism v-m12 (a fallback element).
At the WG's face to face meeting in June 2007 we discussed this issue (RQ-154 Versioning support, in particular forward processing of XSDL) and agreed to continue working on it. On the telcon of 13 July (http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2007Jul/att-0010/2007-07-13telcon.html) [member-only link], the WG reached substantive ('phase-1') agreement on a forward-processing proposal relying not on an xsd:fallback element but on minVersion and maxVersion attributes. The basic idea is that when schema documents are read, they are first pre-processed by being examined for attributes named xvc:minVersion and xvc:maxVersion (the names, especially the namespace, is subject to change). Each is treated as if declared with type xsd:decimal, and the value is compared to a decimal value representing the XSDL version of the schema processor, which I'll represent as "$version". If $version < @xvc:minVersion or $version > @xvc:maxVersion, then the attribute's parent element is suppressed. For example: <xsd:complexType xvc:minVersion="1.1"> <!--* definition suitable for 1.1 and later processors *--> ... </xsd:complexType> <xsd:complexType xvc:maxVersion="1.0"> <!--* definition suitable for 1.0 processors *--> ... </xsd:complexType> In this example, two versions of a complex type definition are supplied, one for 1.0 processors and one for 1.1 and later processors. It may be noted that 1.0 processors can be retrofitted with this mechanism, and that in some cases users of 1.0 processors which have not been retrofitted will be able to perform the preprocessing manually, or to arrange for the environment (e.g. a caching proxy) to perform it. The conformance rules governing schema documents are intended to apply to the schema document AFTER this preprocessing, not before it. A wording proposal is being prepared; I am changing the status keyword accordingly.
In its meeting today, the Working Group considered the wording proposal for forward-processing at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b2825.200707.html (member-only link) and approved it with amendments. The resulting text will be integrated into the status-quo document today. Accordingly, I'm changing the status of this issue to RESOLVED.