This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
For the 4 reference constraints: - acyclic - targetRequired - targetElement - targetType And for the 4 kinds of elements: - non-reference - null-reference - unresolved reference - resolved reference We need to define what to do for all the 16 combinations. It's easy to answer for the "resolved" kinds of the elements: - targetRequired: satisfied - other: check During the 2007-08 F2F, the WG also agreed on the "non-reference" category: - all: satisfied The remaining question is about "null-reference" and "unresolved" categories. It's obvious that "acyclic" should be "satisfied" for both cases. We also agreed (bug 4780) that targetRequired should be "violated". How about targetType and targetElement? That is, we need to define the following 4 cases: null + targetType null + targetElement unresolved + targetType unresolved + targetElement The current draft seems to suggest "violated". But there is desire to change it, at least partially. See http://lists.w3.org/Archives/Public/public-sml/2007Sep/0019.html
Proposal: This should be marked as editorial since it is already covered by Sandy's ref proposal.
The reference proposal covers part of the question raised by this bug, but not all. The remaining question is: If an SML reference is unresolved (that is, sml:ref="true", sml:nilref="false", no target), then - Should targetElement be satisfied or violated - Should targetType be satisfied or violated For completeness, what we did decide: Acyclic targetRequired targetElement targetType Non-reference Satisfied Satisfied Satisfied Satisfied Null Satisfied Violated Satisfied Satisfied Unresolved Satisfied Violated ? ? Resolved Check Satisfied Check Check
Proposal: Both '?' values in the table should be 'Violated'. Acyclic targetRequired targetElement targetType Unresolved Satisfied Violated ? ? The targetElement/Type constraint says that the target element/type must be as specified. We cannot evaluate targetElement/Type constraint for unresolved references. We cannot obviously declare the model to be valid when we are not able to check some constraints. Thus, the most logical choice is 'Violated'. Note that we have already used this reasoning for targetRequired constraint where we define the constraint to be violated for unresolved refs.
> 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".
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 didnt 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 didnt 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.
> targetType/Element violated on unresolved refs unless a yet-be-be-defined > attribute on that ref element says otherwise. Why bother introducing a new one when we already have targetRequired, which is there for this exact reason? Your "reduced trust" arguments all assume that targetType/Element implies targetRequired for *every* schema author. I don't think that's correct. Different people may have different use cases and expect different results. Because we choose to only have a binary outcome for these constraints (satisfied or violated), we have to coerce the answer to one of them. What's listed in comment #4 are reasons why we should coerce to "satisfied": - Consistency - Separation of concern - Cover all cases And the only argument for coercing it to violated I've seen is the belief that "violated" is the *only* expected behavior for *everyone* in the world *forever*. I can hardly believe this. I for one don't think that's the only expectation.
TargetType cannot be considered violated based solely on whether a target is unresolved or not. Consider the use case where the schema author does not want to make the target required but, if present, must be of a specific type. In other words: sml:ref="true", sml:nilref="false", targetRequired="false", targetType="myType" and no target In this case, we cannot consider targetType to be violated for an unresolved reference.
Consensus on 11/8 call Resolution: When you are trying to resolve a scheme and it cannot be resolved due to an error such as network, etc., the entire model is declared to be in an unknown state. Then for an unresolved reference, targetType/Element is declared "satisfied".
Proposal: Based on the resolution in the previsous comment, make the following suggested changes: [1] In section "4.1.2.4 Resolving an SML reference to assess its validity", add the following line just before bullet 2.a: a. If the attempt to resolve fails for at least one scheme then the model validity state is declared to be unknown. [2] Both '?' values in the table (in comment# 2) should be 'Satisfied'. ========================================== Note: The intent of the change# 1 is to ensure that we distinguish between the 2 sub-cases of 'unresolved'. a. the default retreival action of a scheme cannot be completed due to any runtime condition (such as network error, etc.) ==> this leads to model validity being unknown b. the default retreival action of a scheme successfully completes but returns an empty nodeset ==> this is the only case of 'unresolved'.
The intent sounds good. We do need to separate those 2 cases. I would take a different approach in terms of achieving it. Instead of [1] in comment #9, I would add a more general statement to a place like "7. Conformance Criteria", along the following lines: "During the process of SML model validation, all model (definition and instance) documents are always reachable/available. If any model document is not reachable, then how processors behave is outside the scope of this specification and is not performing SML-validity assessment as defined here." This means almost the same requirement for processors as [1] in comment #9: the operation will not provide a valid or invalid answer. But this aligns better with other exceptional cases. For example, if the processor runs out of memory, it's not reasonable to expect it to answer "unknown". "No answer" is a better answer.
I agree that [1] should be moved to the conformance section as described in comment #10.
Sandy/Ginny, it will help if you propose the actual text to use and the place wihin section 7 where it will be inserted.
My proposal for [1] above: Add to conformance section 7, in the section starting with "A conforming SML model is valid if it satisfies all of the following conditions (this is the new text as proposed in Bug #4811):" 5. All documents in the model are available to the model validator. If any model document is not reachable, then the model validator's behavior is outside the scope of this specification.
Works for me. Thus, the modified proposal is: [1] Add to conformance section 7, in the section starting with "A conforming SML model is valid if it satisfies all of the following conditions (this is the new text as proposed in Bug #4811):" 5. All documents in the model are available to the model validator. If any model document is not reachable, then the model validator's behavior is outside the scope of this specification. [2] Both '?' values in the table (in comment# 2) should be 'Satisfied'.
The consensus on 11/8 call was: When you are trying to resolve a scheme and it cannot be resolved due to an error such as network, etc., the entire model is declared to be in an unknown state. Then for an unresolved reference, targetType/Element is declared "satisfied".
ok
Fixed as proposed. [1] Added the following to section "7 Conformance Criteria" part 3: 5. All documents in the model are available to the model validator. If any model document is not reachable, then the model validator's behavior is outside the scope of this specification. [2] Added the following section+table. 4.3.2.5 Target Constraints and SML Reference Categories The following table shows how target constraints are handled for each of the reference categories in the table. Table 4-2. Target Constraints and SML Reference Categories. Acyclic targetRequired targetElement targetType Non-reference Satisfied Satisfied Satisfied Satisfied Null Satisfied Violated Satisfied Satisfied Unresolved Satisfied Violated Satisfied Satisfied Resolved Check Satisfied Check Check