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

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

From: <bugzilla@wiggum.w3.org>
Date: Mon, 29 Oct 2007 19:39:36 +0000
CC:
To: public-sml@w3.org
Message-Id: <E1ImaSW-0004mm-QP@wiggum.w3.org>

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





------- Comment #4 from sandygao@ca.ibm.com  2007-10-29 19:39 -------
> Thus, the most logical choice is 'Violated'.

Well, the most logical choice is "unknown". Whether we want to coerce it to
"satisfied" or "violated" is a decision we need to make.

> have already used this reasoning for targetRequired constraint
> where we define the constraint to be violated for unresolved refs.

This is different. This is not an unknown situation. targetRequired is
specifically there to prevent unresolved references.

Actually, the *opposite* reasoning has already been used for acyclic with
unresolved references, where we mark it as "satisfied".

For targetElement/Type, there are 4 cases:
1 it is known to be satisfied
2 it is known to be violated
3 it's unknown but the schema author wants to tolerate it
4 it's unknown and the schema author doesn't want to tolerate it.

Do we know that #3 will *never* happen? If we go with the "violated" answer,
then #3 can never be achieved. But if we go with the "satisfied" answer, then
#3 can be done by specifying the targetElement/Type constraints, and #4 can be
done by also specifying targetRequirement="true".

This is another example of "separation of concern". There should be one and
only one constraint that governs whether a reference must resolve, and that
constraint is targetRequired.

So counter-proposal: make both '?' "satisfied".
Received on Monday, 29 October 2007 19:39:43 UTC

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