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 Sandy's 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.