W3C home > Mailing lists > Public > public-sml@w3.org > October 2007

[Bug 4774] definitional schema documents should be preferentially used over all other sources when validating instances

From: <bugzilla@wiggum.w3.org>
Date: Wed, 03 Oct 2007 06:09:47 +0000
To: public-sml@w3.org
Message-Id: <E1IcxQZ-00067J-RO@wiggum.w3.org>


------- Comment #2 from kumarp@microsoft.com  2007-10-03 06:09 -------
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

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

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.


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.

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?

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

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.
Received on Wednesday, 3 October 2007 06:09:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:24:23 UTC