http://lists.w3.org/Archives/Public/public-sml/2007Aug/0087.html

Added the contents of a recent related email thread below.

---------
From: Pratul Dublish 
Sent: Thursday, September 27, 2007 7:39 AM
To: Lynn, James (HP Software); Kumar Pandit; public-sml@w3.org
Subject: RE: schema binding proposal : support for conflicting schemas 

IMO, we should not have any optional features in the SML IF spec since optional features are not very useful for interop.  Conforming implementations are not required to support optional features, and hence a producer will hesitate to use this since there is no guarantee that the feature will be supported by consumers.

If we believe that conflicting schemas should be an optional feature of the SML IF spec, then we should not spend time fleshing this out. We should drop this feature and adopt the rest of Sandys excellent proposal.

From: public-sml-request@w3.org [mailto:public-sml-request@w3.org] On Behalf Of Lynn, James (HP Software)
ent: Thursday, September 27, 2007 6:59 AM
To: Kumar Pandit; public-sml@w3.org
Subject: RE: schema binding proposal : support for conflicting schemas 

I agree with Kumar's last paragraph with one possible modification. We could state:
 
1. An implementation is not required to resolve conflicting schemas.
2. If an implementation chooses to resolve conflicting schemas using some heuristic, this would be implementation defined.
 
Jim

________________________________________
From: public-sml-request@w3.org [mailto:public-sml-request@w3.org] On Behalf Of Kumar Pandit
Sent: Thursday, September 27, 2007 2:41 AM
To: public-sml@w3.org
Cc: Kumar Pandit
Subject: schema binding proposal : support for conflicting schemas 
During Toronto f2f meeting, we discussed this proposal but did not reach a consensus. We decided to continue the discussion over email.
 
I had raised questions during the f2f meeting about the following 2 scenarios.
 
[1]
Suppose there are 2 instance documents D1 & D2 corresponding to 2 conflicting versions of a schema. If there is a reference R from D1 to D2 and if R has a targetType/Element constraint on it, how do we enforce the constraint if the type/element involved in the constraint has a conflicting definition? How do we determine if the types/elements are equal? What does type equality mean across 2 conflicting schemas?
 
[2]
How would one enforce an identity constraint if its definition conflicts between the 2 schemas? That is, for example, one identity constraint defines 2 fields and the other defines 3 fields. How would one compute and compare key-sequences?
 
We could come up with more cases like this. May be we should enumerate them all and address them one by one.
 
However, I would like to take a step back, better understand the underlying scenarios and weigh them against the added complexity.
 
I completely agree with the intent of schema binding proposal. It aims to make interop more deterministic which is the right thing to do. I believe, much of the complexity in this proposal is the result of the desire to support conflicting schemas. If that aspect is removed, the proposal becomes straightforward. In my opinion, this would be a good thing to do in the first version of SML spec.
 

Revised proposal from Sandy Gao and Valentina Popescu at http://lists.w3.org/Archives/Public/public-sml/2007Oct/0058.html

Section 4.2.3 When schema binding issues are resolved, need to decide if xsi:schemaLocation content is to be treated as inter-document references in instance documents and/or in definition documents. Also need to decide about removing "xsi:" prefix.

Action Item# 132:
Here are some examples of issues that result due to conflicting schemas. 

example 1: id constraint conflict
---------------------------------

ID is simple-type in one schema and complex-type in another schema.

<element name="foo"> 
    <sequence> 
... ...
    </sequence> 
    <sml:key name="bar" > 
        <sml:selector xpath="deref(students)/student"/> 
        <sml:field xpath="ID"/> 
    </sml:keyref> 
</element> 


example 2: targetType conflict
------------------------------

doc1 uses xsd-v1 and doc2 uses xsd-v2.
There is a ref from doc1 to doc2. The ref has a targetType=FooType constraint on it.
FooType definition is different in the 2 conflicting schemas.


<element name="RefElement1" sml:targetType="tns:FooType"/>

Revised proposal: http://lists.w3.org/Archives/Public/public-sml/2007Nov/0321.html

Summary of key points in the proposal:
1 Add a new element <schemaBindings> (parallel to <ruleBindings> we already have)
2 <schemaBindings> can have any number of <schemaBinding> children, each specifies a schema that's used to validate instance documents listed inside this <schemaBinding>. We can use the same "prefix matching" mechanism as <ruleBindings>.
3 <schemaBindings> can have an optional <defaultSchema> child, to specify the schema used to validate all instance documents not covered any <schemaBinding>.
4 If a <defaultSchema> is not present, then a schema is composed from *all* schema documents and used to validate instances not covered by any <schemaBinding>.
5 Processors are not required to support <schemaBindings> (that is, they are allowed to always compose a schema from all schema documents and use it to validate all instance documents)
6 schemaLocation on <include> and <redefined> are resolved using aliases
7 xsi:schemaLocation attributes and schemaLocation on <import> elements are ignored

fix as per comment #6

2 new sections added to SML-IF document, Section 4.4 and 5.5 both titled "Schema Document Bindings. Added new elements to the SML-IF schema also. 

See the text diff at http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml-if.html%3Frev%3D1.60%26content-type%3Dtext%2Fx-cvsweb-markup&doc2=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml-if.html%3Frev%3D1.61%26content-type%3Dtext%2Fx-cvsweb-markup

1. Not sure whether this is intentional. Seems many spaces are inserted into the pseudo schema in section 4.1. Most elements are indented further than before. And
	    <documentAlias/> * should be
	    <documentAlias/> +
(I probably had this wrong in the proposal.)
2. In section 4.4, for "schema-incomplete". "A required schema is not included ..." Maybe it's more accurate to say "Some required schema documents *may* not be included ...".
3. In the following paragraph "... distinguish between these two cases and that is not always ...". Suggest to change "and" to "because".
4. In the same paragraph "... then, for the instance to be valid, its schema definition documents and ...". The goal here is not "for the instance to be valid". Maybe "... then schema validity of schema definition documents and instances documents depend only on built-in components and components from ...".
5. Before the first example in section 4.4: "whose alias specified in its alias attribute" -> "whose aliases are specified in its aliases attribute". And "... to be assessed against this set of schemas is specified ..." -> "... to be assessed against this set of schemas *are* specified ..."
6. Before the second example: "The defaultSchema can be used cover ..." -> "The defaultSchema can be used *to* cover ..."
7. Section 5.5 doesn't implement the "Processors are not required to support <schemaBindings>" portion of the proposal. Maybe it should start with something like "SML-IF consumers MAY choose to ignore <schemaBindings> the element when it is present in an SML-IF document, in which case the SML-IF consumer SHOULD make its invoker aware of this situation. The rest of this section applies to processors who choose to process the <schemaBindings> element."
8. In the IF schema.
  <xs:element name="schemaBindings"/> should be
  <xs:element name="schemaBindings" type="smlif:schemaBindingCollectionType"/>
9. In IF schema,
      <xs:element ref="ns1:namespaceBinding"/> should be
      <xs:element ref="smlif:namespaceBinding" minOccurs="0" maxOccurs="unbounded"/>
10. Also in IF schema:
  <xs:element name="namespaceBinding" type="ns1:namespaceBindingType"/> should be
  <xs:element name="namespaceBinding" type="smlif:namespaceBindingType"/>
11. IF schema:
    <xs:attribute name="namespace" type="xs:NCName" use="required"/>
    <xs:attribute name="alias" use="required"> should be
    <xs:attribute name="namespace" type="xs:NCName" use="optional"/>
    <xs:attribute name="aliases" use="required">
12. It's not clear to me whether "namespaceBindingType" should also allow extension points using wildcards.
13.   <xs:element name="defaultSchema"/> should be
  <xs:element name="defaultSchema" type="smlif:defaultSchemaType"/>
14. defaultSchemaType should be:
  <xs:complexType name="defaultSchemaType" mixed="false">
    <xs:sequence>
      <xs:element ref="smlif:namespaceBinding" minOccurs="0" maxOccurs="unbounded"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
15. Maybe it's helpful to have a default value for "schemaComplete":
    <xs:attribute name="schemaComplete" type="xs:boolean"/> becomes
    <xs:attribute name="schemaComplete" type="xs:boolean" default="true"/>

Regarding #1, yes the extra spaces were intentional to align the schema contents.

All changes in comment #9 were made except for the following bullets which are copied 
below with my comments:
----------------
2.  In section 4.4, for "schema-incomplete". "A required schema is not included
..." Maybe it's more accurate to say "Some required schema documents *may* not
be included ...".

This does not make sense to me. Either the documents are included or not, in which case 
the IF document is schema-complete or not. I'm not sure what is intended by "may".

---------------
3.  In the following paragraph "... distinguish between these two cases and that
is not always ...". Suggest to change "and" to "because".

The sentence in the spec is "It is necessary for an SML-IF producer to declaratively 
distinguish between these two cases *and* that is not always possible based on the content alone. "

I think "and" is correct. "It is necessary to distinguish..." is a true statement whether or not
it is possible based on content alone - not 'because' it is not possible based on content alone.

--------------
12.  It's not clear to me whether "namespaceBindingType" should also allow
extension points using wildcards.

This needs a group decision.

-------------
15.  Maybe it's helpful to have a default value for "schemaComplete":
    <xs:attribute name="schemaComplete" type="xs:boolean"/> becomes
    <xs:attribute name="schemaComplete" type="xs:boolean" default="true"/>

This needs a group decision. We should be careful to assess the impact of not
setting this correctly. In other words, which is the worst situation:
- schemaComplete is 'true' and the IF document is really not schema complete?
or
- schemaComplete is 'false' and the IF document is actually schema compete?
----------

> Regarding #1, yes the extra spaces were intentional to align the schema
> contents.

I have to admit that the new indention doesn't look as nice as the old way. Why does <identity> need to indent that far when it's parent <model> is at the beginning of the line? Is it because of the "xmlns"? Child elements typically don't align with attributes in the parent tag. (It would be nice if "xmlns" and "xmlns:xs" were aligned.)

But this is not something worth having a war for ... :-) Leaving it up to the editors.

> 2.  In section 4.4, for "schema-incomplete". "A required schema is 
> not included
> ..." Maybe it's more accurate to say "Some required schema documents*may* not
> be included ...".
> 
> This does not make sense to me. Either the documents are included or not, in
> which case 
> the IF document is schema-complete or not. I'm not sure what is intended by
> "may".

There are 2 ways to distinct the 2 cases.
1. Known to be complete vs. not known to be complete
2. Known to be complete vs. known to be incomplete

I always had #1 in mind when thinking about schemaComplete. And the drafted wording takes #2.

I agree that #2 could be more useful in certain cases, especially for consumers, so that they know exactly what to do. But from the producers' perspective, is it always possible to make that distinction? What if it does not have all the information to determine whether some schema documents are missing?

By taking the first interpretation, producers have more flexibility: if they know enough, they can set schemaComplete=true; otherwise it's safe to use "false" (which is not the case for #2). And I don't think this hurts consumers. When complete=true, they never go outside the IF to look for schema documents; when complete=false, consumers can decide what to do.

> 3.  In the following paragraph "... distinguish between these two cases and
> that
> is not always ...". Suggest to change "and" to "because".
> 
> The sentence in the spec is "It is necessary for an SML-IF producer to
> declaratively 
> distinguish between these two cases *and* that is not always possible based on
> the content alone. "
> 
> I think "and" is correct. "It is necessary to distinguish..." is a true
> statement whether or not
> it is possible based on content alone - not 'because' it is not possible based
> on content alone.

Hum... I would say the reason it is "necessary" is because "it is not possible to tell". If a comsumer can always tell, then why do we require producers to distinguish?

> 15.  Maybe it's helpful to have a default value for "schemaComplete":
>     <xs:attribute name="schemaComplete" type="xs:boolean"/> becomes
>     <xs:attribute name="schemaComplete" type="xs:boolean" default="true"/>
> 
> This needs a group decision. We should be careful to assess the impact of not
> setting this correctly. In other words, which is the worst situation:
> - schemaComplete is 'true' and the IF document is really not schema complete?
> or
> - schemaComplete is 'false' and the IF document is actually schema compete?

Oops. Meant for the default to be "false".

Whether to have this default makes no real difference. The only place it affects is probably when we talk about the value of this attribute. Without the default, we need to say "if ... is present and its value is ..."; with the default, we know the attribute will always be there, then we can simply say "if ...'s value is ...".

Regarding Sandy's point #2 in comment #11, I believe the name of the attribute is somewhat at fault for the ambiguity.  Using schemaComplete T or F would support the second interpretation: Known to be complete (schemaComplete='true') vs. known to be incomplete (not complete, schemaComplete='false')--the "knowledge" factor is implicit in the attribute assignment.  The attribute should be knownSchemaComplete to support the distinction between known to complete vs. not known to be complete so that the "false" (not) more clearly qualifies the "known" part.

I would agree that the "knownSchemaComplete" is the better alternative from the producer's perspective.

Regarding #1 (spaces) - I was looking at the schema not the pseudo-schema. I'll fix the spaces in the pseudo-schema - that was an accident.
The rest I will leave open for further group discussion. 

I apologize for reviewing this very late. My observations are:

[1]
I believe that the following 2 points from comment# 6 should apply even when a consumer ignores the <schemaBindings> element.

6 schemaLocation on <include> and <redefined> are resolved using aliases
7 xsi:schemaLocation attributes and schemaLocation on <import> elements are
ignored

However, the spec currently defines this behavior only for consumers that choose to process the <schemaBindings> element.

[2]
I am not sure I understand the sentence (from section 5.4.2 Bindings defined) below:

"Although SML-IF itself does not do so, various uses of SML-IF MAY choose to extend the sets of documents involved in bindings to include documents not contained in the interchange set."

I am not necessarily opposing this but I would like to know what this means in a normative section.

[3] Consumers that ignore the <schemaBindings> element:
The spec clearly defines the behavior when consumers choose to use the <schemaBindings> element. The spec should also define the behavior when a consumer ignores the <schemaBindings> element. How is the schema-set formed? I assume that the ansers is: It is formed using all schemas (embedded or referenced) in the SML-IF document. This is also related to [1].

wrt http://www.w3.org/Bugs/Public/show_bug.cgi?id=4774#c14 part [2] only:
this is nominally unrelated to 4774 although it may point out the need for a change to the schema binding text.  IIRC it has been there since the original submission.  It is related to rule bindings, not schema bindings.  The "For example,..." following the quoted sentence attempts to explain the quoted sentence.

My interpretation of the quoted sentence is that it clarifies the intent that the rule bindings text should not be read by spec lawyers as limiting.  I.e., it explicitly allows an SMLIF consumer to bind rule document X to other SML documents outside the interchange set that the consumer might have lying around.  e.g. if the SMLIF consumer is front-ending a persistent store of SML documents, all with URI prefix urn:foobar:mydocs and the consumer receives an SMLIF consisting only of a rule document X bound to urn:foobar:my (but there are zero model instance documents in the SMLIF doc), then the consumer is allowed to bind rule document X to all SML documents in the consumer's store because of URI aliasing.  SMLIF does not define how to do this (eg if URI aliasing is even used), or require a consumer be able to do this (i.e. it is not prescribed), and SMLIF does not prevent this (it is not proscribed).  Some spec lawyers read "you can do A via mechanism B" to be limiting, i.e. to say that "you can ONLY do A if you use mechanism B", and apparently that is not the intent for rule bindings (or we have text that incorrectly reflects our wishes, or I got my As and Bs mixed up).

It is a pertinent question to ask, since I do not see corresponding text for schema bindings, if the same text should exist for schema bindings.  If we decide we do not like the cited text (in rule bindings) that would belong in a separate bug I think. 

My off the cuff opinion is that we have the same intent for schema bindings, i.e. do not want to artificially limit their usage.  So while SMLIF does not talk about applying those bindings to documents outside the interchange set, if a consumer chose to use SMLIF extension points or a proprietary mechanism to apply those bindings to other documents, we would allow that.  

I know it's a bit strange if you read specs a certain way (i.e. with a certain set of assumptions) to think about describing what you're NOT doing, but experience has shown that readers are "creative" and "diverse" with the assumptions they use to interpret spec words.  You can write it with the intent to describe what is "in", assuming that silence about the rest means you implicitly allow it; others can read it to say what you are silent about is implicitly DISallowed.  The more explicitly the authors' assumptions are captured, the less room there is for diverse interpretations.

wrt http://www.w3.org/Bugs/Public/show_bug.cgi?id=4774#c14 [1] and [3]

Looking at the editors draft, the 2nd sentence of 5.5 schema bindings says "The remainder of this section applies to SML-IF consumers who choose to process the schemaBindings element."  Meanwhile, just before the end, there is conflicting text: "Otherwise, an SML-IF consumers MUST  compose a default schema using *all* schema documents included in the SML-IF document. An SML-IF consumer MUST use this default schema to validate those SML instance documents that are not included in any schemaBinding."

The first quote leads to the problems cited in [1] and [3].  The second I think actually satisfies the intent of [3], but the first quote logically negates it.

This seems like a fairly easy to fix structural issue with the text.  One way to address this would be:

5.5 Schema Bindings [remove existing first paragraph]
We probably need to do this no matter what else we do.

5.5 Schema Bindings
The set of schema documents used to validate each model instance document can be specified in one of several ways:
1. A model instance document MAY be explicitly bound to a particular set of schema documents, i.e. through a schemaBinding element.  A consumer that supports the schemaBinding element MUST use such an explicit binding if it exists.  A consumer that encounters an explicit binding but does not support the schemaBinding element SHOULD make its invoker aware of this situation.
2. A model instance document MAY be implicitly bound to a particular set of schema documents, i.e. through a defaultSchema.  A consumer that supports the schemaBinding element MUST use such a binding unless the model instance document was explicitly bound to a set of schema documents (i.e. through a schemaBinding element).  A consumer that encounters an explicit binding but does not support the defaultSchema element SHOULD make its invoker aware of this situation.
3. If a model instance document is not bound to a particular set of schema documents, or if the consumer does not support those binding mechanisms, then the SML-IF consumer MUST  compose a default set of schema documents using all schema documents included in the SML-IF document.
[then break each distinct case into a sub-section, and reference from each bullet above]

An equally acceptable alternative (to me), would be to turn some existing text into a list, increasing the nesting depth of the existing list in this section. The outer-most list items would be
1. For each
2. If default schema
3. otherwise
The text for 1 and 2 would have to be qualified so that only consumers that understand schemaBindings MUST ... 

Summary of points that may need WG discussion.

From comment #9:

2.  In section 4.4, for "schema-incomplete". "A required schema is not included
..." Maybe it's more accurate to say "Some required schema documents *may* not
be included ...".

---------------
3.  In the following paragraph "... distinguish between these two cases and
that is not always ...". Suggest to change "and" to "because".

--------------
12.  It's not clear to me whether "namespaceBindingType" should also allow
extension points using wildcards.

-------------
15.  Maybe it's helpful to have a default value for "schemaComplete":
    <xs:attribute name="schemaComplete" type="xs:boolean"/> becomes
    <xs:attribute name="schemaComplete" type="xs:boolean" default="true"/>

(Really meant for the default to be "false".)

----------
And from comment #14

[1]
I believe that the following 2 points from comment# 6 should apply even when a
consumer ignores the <schemaBindings> element.

6 schemaLocation on <include> and <redefined> are resolved using aliases
7 xsi:schemaLocation attributes and schemaLocation on <import> elements are
ignored

----------
[2]
I am not sure I understand the sentence (from section 5.4.2 Bindings defined)
below:

"Although SML-IF itself does not do so, various uses of SML-IF MAY choose to
extend the sets of documents involved in bindings to include documents not
contained in the interchange set."

----------
[3] Consumers that ignore the <schemaBindings> element:
The spec clearly defines the behavior when consumers choose to use the
<schemaBindings> element. The spec should also define the behavior when a
consumer ignores the <schemaBindings> element.

point 2 in comment #9 in 17 - fix per rewording 
point 3 in comment #9 in 17 - fix per proposal
point 12 in comment #17 - add wildcard as in other type definitions
point 15 in comment #17 - make schemaComplete required and no default value

point [1] in comment #17 - section 5.5, item #3 should be followed regardless of whether schemabinding present or ignored.
point [2] in comment #17 - editors choice
point [3] in comment #17 - editors  to fix; first sentence in section states that section applies to when schemabinding is ignored which is not true for this statement in 2nd to last paragraph.

Please review  sections 4.4 and 5.5 - this bug is very confusing.
The complete version: http://dev.w3.org/cvsweb/~checkout~/2007/xml/sml/build/sml-if.html?rev=1.81&content-type=text/html;%20charset=iso-8859-1
Diff version: http://dev.w3.org/cvsweb/2007/xml/sml/build/sml-if.html.diff?r1=1.80&r2=1.81&f=h

plus schema changes are:

  <xs:complexType name="namespaceBindingType" mixed="false">
    <xs:attribute name="namespace" type="xs:NCName" use="optional"/>
    <xs:attribute name="aliases" use="required">
      <xs:simpleType>
        <xs:list itemType="xs:anyURI"/>
      </xs:simpleType>
    </xs:attribute>
    <xs:anyAttribute namespace="##other" processContents="strict"/>
  </xs:complexType>
...
  <xs:complexType name="documentCollectionType" mixed="false">
    <xs:sequence>
      <xs:element ref="smlif:document" maxOccurs="unbounded"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="schemaComplete" type="xs:boolean" use="required"/>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
 

(In reply to comment #19)
>   <xs:complexType name="namespaceBindingType" mixed="false">
...
>     <xs:anyAttribute namespace="##other" processContents="strict"/>
>   </xs:complexType>

Strict should be lax, like the other anyAttributes, no?

(In reply to comment #19)

The text looks great.

Suggestion:
> It is necessary for an SML-IF producer to declaratively distinguish between these two cases because that is not always possible based on the content alone.

might be improved via

from: because that     is not always possible based on
to:   because doing so is not always possible based on

I always take mental page faults on indefinite articles.  Longer, even more specific replacement text (e.g. below) is also fine, I was just doing a "how bad is it" trade-off to get to what I have above.

from: because that                    is not always possible 
based on
to:   because making that distinction is not always possible for a consumer based on

Fixed schema per comment #20.

Fixed section 4.4 per comment #21. New sentence is:

It is necessary for an SML-IF producer to declaratively distinguish between these two cases because making that distinction is not always possible for a consumer based on the content alone.