This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, Schematron assertions are allowed only on top-level element declarations and type definitions. Some members of the WG are puzzled by this and suggest that it is insufficiently motivated as part of the design. We need to consider whether to retain this restriction. There may be some interaction with the rule that Schematron constraints must be inherited across restrictions of enclosing complex types.
Pratul will write a proposal.
I am including Michael's and Sandy's proposal for sake of completeness. Resolution reached in Thu conf call on 12/6/07 <MSM> Proposal: 1 retain the existing rule allowing assertions only on global elements. 2 make an explicit rule that the restriction invariant must hold w.r.t. schematron assertions (as well as target* etc). 3 optionally observe that this means that a complex type R restricting a complex type B cannot replace a reference to a global element E in B with a local element E in R, if the global E has assertions. [11:55] <Sandy> 1. assertions can only be specified on global element declaraions [11:57] <Sandy> 2. assertions can only be specified on global complex type definitions <Sandy> 3. assertions can be available on anonymous complex type (only via derivation/inheritance) <Sandy> 4. assertions must satisfy complex type restriction rules (similar to target* constraints) <Sandy> 5. if complex type T2 restricts complex type T1; T1 contains a reference to global element E with assertions; T2 contains a local E without assertions. This will be a restriction error. <Sandy> 6. if compelx type T2 restricts complex type T1 and T1 has assertions, then those assertions are unioned with any other assertions specified on T2, if any. <MSM> addendum: when complex type B has assertions, they are automatically copied to / inherited by any restriction R of B, and unioned with the assertions specified on the declaration for R. [11:58]
The fix involves a large number changes, rearrangement and separation of normative/non-normative content within chapter 5. Rules. Please refer to the updated spec for reviewing the changes.
My review comments: http://lists.w3.org/Archives/Public/public-sml/2007Dec/0104.html
Almost all of the suggested changes have been made. I have noted inline where I deviated from the suggestion. ------------------ 1. Section 5.0 mainly contains non-normative information (examples, explanations). The only exception is the following sentence: "If an assert or report is violated, then the violation MUST be reported during model validation together with the specified message. Model validation MUST evaluate each Schematron pattern for all of its applicable elements contained in the model." which is now covered in 5.2.1.3. Suggest to remove it from 5.0. [kumarp] done. The first sentence was moved to 5.2.1.3 since it was not already covered by that section. The second sentence was deleted. 2. Suggest to change the title of 5.2 to "Rules Embedded in Schema *Documents*" [kumarp] done 3. Suggest to remove 5.2.1 and put its content in 5.2. (Note that there is no 5.2.2.) [kumarp] done. 4. Need to be consistent *Schematron* vs. *schematron*. [kumarp] done. Also sometimes the rules are referred to as "constraints" and sometimes "patterns". Each complex type/element declaration can have multiple "xs:appinfo" and each "xs:appinfo" can have multiple "sch:schema", so each complex type/element declaration can potentially have multiple Schematron schemas. And each such schema may have multiple patterns. Maybe the {rules} should really be "a set of Schematron schemas"? [kumarp] I like the word constraint because it also aligns with other parts of the spec (ref constraints, identity constraints, etc.). However, I agree that we should consistently use the same word, therefore I defined it in the Terminology section as: Schematron Constraint The information contained within a single sch:schema element. I referenced this definition where appropriate for consistency. 5. Section 5.2.1.1. "It MUST NOT be attached to any other kind of schema component." It's not clear whether this is at the syntax level or component level. This is important for anonymous complex types (those without a name attribute and embedded inside <xs:element> elements). What we said during 2007-12-06 telecon was that, for anonymous types, Schematron rules are not allowed at the syntax level, but is allowed at the component level, when they inherit rules from their base types. I see a few options: a. Change our decision from 2007-12-06 and say "if a global base type has rules, then one can't derive an anonymous type from it, because anonymous types are not allowed to have rules". This will make rules much less useful. b. Change our decision and say "rules are allowed on all complex types, including anonymous, both in syntax and in the abstract component model". I don't see any harm if we go with this approach. The main reason for only allowing rules on globals was because of local *elements*, not types. c. Keep our earlier decision, and change 5.2.1.1 to clarify that the quoted sentence only applies to the syntax. If we go with this route, we can replace the first paragraph in 5.2.1.1 to: "sch:schema elements can be embedded in members of the {application information} of the {annotation} of a global element declaration or a global complex type definition. They MUST NOT be embedded in any other kind of schema component." This fits better in section 5.2.1.1, because this section is about syntax -> model mapping, so constraints should be described in terms of the syntax. [kumarp] done. 5. Section 5.2.1.1, bullet 2. Simple type definitions don't have {rules}. Should remove this bullet. [kumarp] done. 6. Bullet 4, because the base type definition can be a simple type, need to have 2 different cases: if base is complex, then union; otherwise use local-rules. [kumarp] done. 7. 5.2.1.2, bullet 1. This again contradicts our decision that anonymous complex types can have rules via inheritance. This rule should only apply to element declaration. Also it should use the property {rules}. i.e. "{rules} for local element declarations MUST be the empty set." [kumarp] done 8. For all target* constraints and identity constraints, we have a rule "if 2 element declarations of the same name appear in the same complex type, then they must have the same {target*/identity constraints}". Do we want the same for {rules}? If we do, we can add the following bullet: [kumarp] We discussed in the conf call that there is no easy way to define equality for schematron constraints. Thus even if we define this condition, we cannot really enforce it correctly in all cases. "If 2 element declarations E1 and E2 have the same {namespace name} and {name} and they are both contained (directly, indirectly, or implicitly) in a content model of a complex type, then E1 and E2 have the same set of {rules}. Note: this implies that a global element declaration with non-empty {rules} cannot be included in the same complex type definition as a local element declaration." [kumarp] Please see the earlier comment. Defining same set of rules is not easy. 9. 5.2.1.2, bullet 2.a. The "automatically copied" rule is already covered in 5.2.1.1 bullet 4. What we should say in 5.2.1.2, if anything, should be that "If complex type definition D is derived from another complex type definition B, then D'{rules} is a super set of B's {rules}." [kumarp] Since we automatically copy rules from base type to the derived type, is there a case where Ds rules can be a subset of Bs rules? I cannot think of any such case. If there is no such case then this rule is redundant. Further, I want to avoid the word superset because we will need to define it. What does superset really mean in this case? The number of rules is same or more? Or rules are identical and additional rules are added? If so, what does identical mean? I wanted to avoid this confusion therefore I have worded the text to avoid the word superset. Also note that this should apply to both restriction and extension. (i.e. extension can't remove {rules}.) This should become bullet 2. [kumarp] Agreed about the behavior being true for both restriction and extension. I have reflected this in the new bullet# 3. I have retained the automatically-copied wording because I want to avoid confusion over whether the union of {rules} is performed by the SML validator or by schema author (by hand). 9. 5.2.1.2, bullet 2.b.iii. -> "EB is a global element declaration ..." 10. 5.2.1.2, bullet 2.b. The reason the case described in 2.b is an error is because it violates the "restriction" rule, which is not clear from all the bullets. Suggest to replace it with a more general rule, and list this particular case as a note/example. i.e. use the following as the new bullet 3 (which is also consistent with similar wording in other sections): "For a complex type D derived by restriction from its {base type definition} B, if ED is included in D and EB is included in B and ED and EB satisfies the "NameAndTypeOK" constraint (for XML Schemas definition of valid restrictions, see Schema Component Constraint: Particle Valid (Restriction), Constraints on Particle Schema Components in [XML Schema Structures]), then {rules} of ED MUST be a superset of that of EB. Note: this implies that if a global element declaration with non-empty {rules} is included in a base type definition, then it cannot be restricted to a local element declaration." [kumarp] I agree that the purpose of the bullets was unclear. I added the wording above and retained the earlier bullets. This way I can avoid using the word superset and still achieve the end result. 11. See comment 4. Depending on what {rules} contains (set of schemas, patterns, constraints, rules, assertions, ...), 5.2.1.3 needs to be written differently. 12. 5.2.1.3. Should refer to {rules} and fix up the bullet numbers. e.g. "1. Each Schematron schema/pattern/constraint in {rules} of a complex type definition CT MUST be evaluated for all element instances of CT in a model. 2. Each Schematron schema/pattern/constraint in {rules} of a global element declaration ED MUST be evaluated for all element instances of G in a model. 3. As defined in the Schematron specification [ISO/IEC 19757-3], a Schematron schema/pattern/constraint MUST be evaluated for an instance element by ..." [kumarp] done. 13. (Not directly related to this bug.) The title of section 5.4 is confusing. It's really not about a "profile". The only thing said in this section is "default queryBinding is xslt, which is required to be supported". Maybe this section can be combined with 5.1. [kumarp] done
Copying my comments made in email... Most changes mentioned in comment #5 look good. 2 additional comments: 1. "5.3.2 Schema Validity Rules" Bullet 1 is implied by bullet 2: "2. The value of {rules} for a local element declaration MUST be the empty set." 2. How much do we need to say in "instance validity rules" sections In most case, we just say "the instance MUST satisfy ...", without mentioning "report violation" or "invalid". But bullet 4 of 5.3.3 has: "If an assert or report is violated, then the violation MUST be reported during model validation together with the specified message. The model MUST be declared invalid when this happens." It is better to treat all constraints consistently. Maybe a. Recast the sentence to follow the "instance MUST" pattern, and b. Have "invalid" etc. only in the conformance section.
Fix per comment #6.
FIxed as suggested in comment# 6. [1] Removed bullet #2. [2] changed the following: from: If an assert or report is violated, then the violation MUST be reported during model validation together with the specified message. The model MUST be declared invalid when this happens. to: All of the assertion tests in fired rules MUST succeed. The wording is based on the following terms defined in the schematron spec: 3.6 assertion test assertion modelled or implemented by a Boolean query; an assertion test "succeeds" or "fails" 3.23 valid with respect to a schema member of the set of XML documents described by the schema: an instance document is valid if no assertion tests in fired rules of active patterns fail
(In reply to comment #8) Looking at this in context, I see two things. 1. We lost any connection to an "associated message" during the edit. It is not obvious to me if this a good thing or not, intentional or not, ... 2. If I were reading that section, nothing would suggest to me that "assertion test" or (and especially) "succeed" were Schematron-specific terms. If there is a convenient way to refer to each definition, that would be optimal. I suspect that cross-document references are problematic however, in which case I would fall back to inserting a [Schematron] reference after each "special" word we are intentionally re-using from their spec. I considered adding just one [..] at the end of the sentence, but that seemed insufficient to communicate the "specialness" of both words to me. As someone who has not really lived much in the Schematron spec, I am probably a decent gauge of the average reader's understanding in this case. For some, having two [..] in one sentence will no doubt feel like being clubbed, but I'd rather be pedantic than unclear.
(In reply to comment #9) > 1. We lost any connection to an "associated message" during the edit. It is withdrawn... got 1st and 2nd reversed. > 2. If I were reading that section, nothing would suggest to me that "assertion > test" or (and especially) "succeed" were Schematron-specific terms. If there withdrawn... once I read full hardcopy, i.e. with more context, was clear enough.
in 5.3.2, change the following: from: It MUST NOT be non-empty for any other schema component. to: It MUST be empty for any other schema component.
RESOLUTION: adopt changes in comment #8 of 4644, with the above 4 amendments. MSM: now pursuaded that the decision we made on Dec. 6 is good (to mark the above situation as "error" and not "inheritance". suggest to move sub-bullets of 3 (in 5.3.2) into a note. and replace "as" with "is". to replace "It MUST NOT be non-empty" with "It MUST be empty" Also change "Consequently, it as an error if all of the following is true." to "Consequently, it is an error if all of the following are true."
All changes made as suggested in comment# 12.