This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
SML spec describes under section 3. Dependencies on Other Specifications, a floor for schema versions used by SML. It also leaves the ceiling open, which means conforming implementations may choose to use versions higher than the specified floor. The question is whether IF should say anything about cases where exchanged data is SML compliant but the IF producer and IF consumer are using different versions of required schemas. Does this result in interop not being possible ? Or leaves room for the two consumers to try to make it work by adjusting data in such a way that they can understand each other? An an example: one SML model supports XPath 2.0. Data is exported from this model into an IF document for exchange with another SML repository. The target SML repository does not implement XPath 2.0. In this scenario we deal with two conforming SML models but since they use variations of the same schema, interop is not possible at least in one direction.
Add some clarifying comments to the non-normative part of the spec. Editors should submit the changes to the WG for review
Section 2 modified to add a 'Note:' regarding usage of newer versions( this content may move to a non-normative section as part of the work for separating spec into normative and non-normative sections; at this time the best place for this content seems to be here ) 3. Dependencies on Other Specifications Other specifications on which this one depends are listed in [Normative_References]. Conforming implementations of this specification MUST support SML 1.1 [SML 1.1], XML 1.0 [XML] and XML Schema 1.0 [XML Schema Structures, XML Schema Datatypes]. Conforming implementations MAY additionally support later versions of the XML or XML Schema specifications. >>>Note: Although SML 1.1 and SML-IF allow conforming implementations to support newer versions of dependent specifications, there are interoperability implications to be considered when documents based on those versions are interchanged using SML-IF. When an SML-IF document interchanges data built using newer versions of the SML and SML-IF dependent specifications, consumers of the SML-IF document not supporting these versions may not be able to interpret some of the data exchanged by this document.
link to the change described in comment #2 ( inline text may be hard to read ) http://dev.w3.org/cvsweb/~checkout~/2007/xml/sml/build/sml-if.html?content-type=text/html;%20charset=utf-8#Dependencies
wg review in the 11/28 call: suggest to change "may not be able" to "may be unable", because "may not" could be read as "must not".
fixed as amended by comment #4