Initial proposal is attached to the following email:

http://lists.w3.org/Archives/Public/public-sml/2008Jan/0030.html

Based on http://www.w3.org/Bugs/Public/show_bug.cgi?id=4774#c18 and the proposed move of schemaComplete into this header section, this header becomes required not optional.

Conformance level as a non-extensible string enumeration strikes me as overly constraining.  Given your Qname vs URI discussion, seems like it should be a URI (IRI) not a string, which also makes it extensible.  Strings are fine for human-readable specs, less so for concepts targeted to automated processing.

Version is something I don't remember discussing.  What is it, what is its semantic, what value should a producer place in it, how would a consumer use it, what is its syntax, what implicit assumptions about its use might be buried in that syntax, etc.

Clarification: refScheme URI is present once for each ref scheme both known to the producer and used anywhere in the IF?  A consumer uses this how?

Explain to me again what schemaComplete has to do with wideness or degree of interop?  http://www.w3.org/Bugs/Public/show_bug.cgi?id=4774#c18 makes it required with no default, and I think it is a setting that must be observed regardless of whether or not schema bindings are processed.  At least that's my understanding of where we landed.

The dependencies between various elements ('if conformance level is X, you'd better include ref scheme Y in the list -or- omit the ref scheme lists') feels like it introduces complexity.  I was sort of expecting a set of orthogonal bits.  Maybe some combinations would be valid (or consistent) and some not, but I was relatively ok with that.

Initial Responses to John's comments item #2:

Based on http://www.w3.org/Bugs/Public/show_bug.cgi?id=4774#c18 and the
proposed move of schemaComplete into this header section, this header becomes
required not optional.
RESPONSE: My apologies, I had completely forgotten about that decision.  You are correct.  I did not intend to go back on that decision.  (I would point out that the SML-IF states that "It is necessary...".  The text should be rephrased to use the normative langage of RFC 2119).

Conformance level as a non-extensible string enumeration strikes me as overly
constraining.  Given your Qname vs URI discussion, seems like it should be a
URI (IRI) not a string, which also makes it extensible.  Strings are fine for
human-readable specs, less so for concepts targeted to automated processing.
RESPONSE: Conformance levels depend on what is defined in SML-IF 5.1.  I should have used "Level 1" and "Level 2" (or "Full" and "Minimal"), but I was anticipating changing those as per my comment on 4675:http://www.w3.org/Bugs/Public/show_bug.cgi?id=4675#c28.  I would be more than happy if the SML-IF defined URIs for these levels of conformance!

Version is something I don't remember discussing.  What is it, what is its
semantic, what value should a producer place in it, how would a consumer use
it, what is its syntax, what implicit assumptions about its use might be buried
in that syntax, etc.
RESPONSE: SML-IF version was mentioned in issue description below.  I agree, more thought might be given to this if we decide to proceed.

Clarification: refScheme URI is present once for each ref scheme both known to
the producer and used anywhere in the IF?  
RESPONSE: Yes
A consumer uses this how?
RESPONSE: Perhaps to determine what modules for reference scheme processing might need to loaded to process the document.

Explain to me again what schemaComplete has to do with wideness or degree of
interop?
RESPONSE See third bullet in the Interoperability of SML models section in http://www.w3.org/Bugs/Public/show_bug.cgi?id=4675#c27



 

Second proposal dealing with only SML-IF version number:

http://lists.w3.org/Archives/Public/public-sml/2008Jan/0084.html

Proposal in comment #4 accepted with the following changes:

In proposed 5.1.1:
 - change sentence to: This value MUST be "1.1". [note to editors] Optionally, add non-normative note that this value will be different for future versions of this specification.

 - change following sentence to: Consumers MUST attempt to process an SML-IF document regardless of the value of the SMLIFVersion attribute.  

 - Remove sentence: Consumers MAY abort if they encounter a data feature that they do not understand.

-  Change last sentence and move to an appropriate place: The SMLIFVersion number may assist in debugging the cause of any identified errors.

- Remove last sentence in proposes 5.1.1: "No assumption SHOULD..."

Schema is per next comment.

The SMLIFVersion attribute is to be allocated to the modelType complex type.  The revised XML Schema is as follows:

<xs:complexType name="modelType" mixed="false">
  <xs:sequence>
    <xs:element name="identity" type="smlif:identityType"/>
    <xs:element ref="smlif:ruleBindings" minOccurs="0"/>
    <xs:element ref="smlif:schemaBindings" minOccurs="0"/>
    <xs:element name="definitions" type="smlif:documentCollectionType" minOccurs="0"/>
    <xs:element name="instances" type="smlif:documentCollectionType" minOccurs="0"/>
    <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="SMLIFVersion" type="xs:token"/>
  <xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>

added section the following section:
-------
5.1.1 Using the SML-IF Version Attribute
An SML-IF producer MAY specify the version of the SML-IF specification with which conformance is declared by including the version number of the relevant specification as the value of the SMLIFVersion attribute in the document's model element. This value MUST be "1.1" for documents conforming to the SML-IF 1.1 specification. Consumers MUST attempt to process an SML-IF document regardless of the value of the SMLIFVersion attribute. Therefore, a consumer of SML-IF document MUST NOT reject the document simply on the basis that it has a different version of the specification. 

Non-normative note: The SMLIFVersion number may be useful when diagnosing failures enountered while processing SML-IF documents. 
----------

Also, updated the sml-if schema and the pseudo schema in section 4.1 as suggested and added the following non-normative para in 4.1:

A document producer can specify the version of the specification under which the current document was generated, and with which conformance is claimed, in the SMLIFVerion attribute. For example, if this version of SML-IF is used as the basis of a document, the value of this attribute would be the value "1.1". 

The text subtly strayed from an assertion about the producer's intent to one about the document itself (i.e. something independent of the producer).  

Let's say SMLIF's next version is called 1.2, and it is a compatible extension of 1.1, so all 1.2-compliant documents are also 1.1-compliant.  Presumably the matching section would say the conforming document version is 1.2.  If we state a MUST about the document itself, then a 1.2-compliant document (which is also 1.1-compliant) MUST have two distinct values for the version, 1.1 AND 1.2, yet the schema maxOccurs==1 (implicitly) since it is an attribute.

There are at least two easy outs here: 
(1) make version a multi-valued element (i.e. maxOccurs=unbounded) or 
(2) change the sentence as follows to make it a statement about the producer's intent

from: This value MUST be "1.1" for documents conforming 
      to the SML-IF 1.1 specification.
to:   This value MUST be "1.1" for documents declared by the producer to conform      
      to the SML-IF 1.1 specification.

I propose #2 (mild preference), as it results in a more compact document when used and requires only a text change, and a human noting the 1.2 compliance assertion would either know or be able to determine via the specs the relationship between compliance of a document with the asserted level and other levels (in my example, this means knowing that every 1.2-compliant doc is also 1.1-compliant).

Agree with option #2 in Comment #8

Agree with option #2 in Comment #8

Fixed as suggested in option #2 in Comment #8