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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4774





------- Comment #15 from johnarwe@us.ibm.com  2007-12-13 14:34 -------
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.

Received on Thursday, 13 December 2007 14:35:09 UTC