[Bug 5040] Hanlding of reference constraints on different kinds of elements

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





------- Comment #5 from kumarp@microsoft.com  2007-11-08 01:40 -------
I see a couple of problems with this approach.

1. Reduced trust in the validity of a model:
--------------------------------------------
When a validator declares a model to be valid, I should be able to trust that
the model is really valid. This is a key requirement of many product scenarios.
When I am updating/adding a number of documents to a store, I must make sure
that the store state remains consistent. In other words, I should only allow
the updates to take place if the resultant model is valid. Here ‘valid’ must
mean a 100% guarantee and not the result of a good faith effort. If constraints
are declared satisfied when the validator is unable to check them then this
fundamental requirement is broken.

2. Reduced trust in constraint enforcement:
-------------------------------------------
When a schema author adds a constraint to a reference, it is with the intent
that the reference must satisfy the constraint. If the schema author didn’t
care whether the constraint is satisfied then she/he is not likely add it in
the first place. A reference can be unresolved due to many runtime conditions
(for example, a network glitch). A schema author can never predict runtime
conditions, therefore she/he will never be able to predict when the constraint
will actually be enforced or when it will be declared satisfied because a
reference didn’t resolve. This means that potentially every reference in a
model can be unresolved and yet satisfy constraints. If a schema author can
tolerate every reference to potentially skip the constraint check, what is the
real world scenario where the author would want to add a constraint? In that
case, to require a validator to enforce a constraint a schema author will need
to add targetRequired on every reference where another appropriate constraint
has been specified. Thus, in the degenerate case, every reference constraint
will need to be accompanied by a targetRequired constraint. This is overly
restrictive for a schema author. Why should a schema author be forced to add
targetRequired constraint on every reference if another constraint need to be
specified?

The basis of supporting ‘satisfied’ on unresolved refs seems to be case # 3 in
the earlier comment (“ 3. it's unknown but the schema author wants to tolerate
it”). I believe this case is not based on a real world scenario as I have noted
above. However, I am open to considering a solution to this case if it helps
reach consensus faster. 

If a schema author wants to tolerate constraint check failures, he should be
able to explicitly declare this intent using some means. This should not be
implicitly assumed because there is no targetRequired constraint. We could
define a separate attribute such as sml:enforce=”lax” to allow a schema author
to declare this intent. 

Modified proposal to accommodate case# 3:
targetType/Element violated on unresolved refs unless a yet-be-be-defined
attribute on that ref element says otherwise.

Received on Thursday, 8 November 2007 01:41:08 UTC