This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(discussed 1/22 f2f) There are two places in 5.3 (+1 in section 6) where very similar, but different, sets of constructs are listed. We need to be sure that either they are validly different (and we have a story for why) or they are consistent. MSM and Sandy to agree on what the text _should_ say, since after several iterations in the room no clear agreement emerged. 5.3.1 Mapping from schema "Let local-rules be the set of Schematron constraints attached to a global element declaration or a global complex type definition." 5.3.2 Schema Validity Rules, item 1 "The value of {rules} MAY be non-empty for global element declarations, global complex type definitions or anonymous complex type definition of global element declarations. " 6. Localization of natural-language messages, item 2 "sch:assert and sch:report in a Schematron pattern embedded in the xs:annotation/xs:appinfo element for a complex type definition or an element declaration."
01/31 meeting resolution to mark bug as needsAgreement actions opened to come up with proposals
Sandy Gao and I took an action to prepare a proposal to resolve this; we have not yet reached agreement on what to propose, but we have noted a couple of points that should probably be considered by the WG. 1 The current phrasing in 6.3.1, which talks about sch:schema elements being embedded in the {application information} of the {annotation} property of a schema component, is designed to cover both the common case where the schema component was created by reading a source declaration in a schema document, and the other possible case ('born binary comnponents') in which it was created by some other means. But 6.3 is titled "Rules embedded in schema documents". If the intent is that Schematron rules are only legal if a schema document is used, then the wording in 6.3.1 can / should change. If (as seems more likely) the more general wording in 6.3.1 is the right thing, then the title of 6.3 should probably change. Ditto for the title of 6.3.1. 2 Section 6.3.1 describes the embedding of sch:schema elements in terms of XSD component properties; section 7 describes them in terms of schema document elements. Is there is a reason for these two not to be aligned? or should they both speak in terms of component properties? (Or in terms of elements in schema documents -- less general, but in some ways simpler and more concise.)
Created attachment 521 [details] Changes suggested by Michael and Sandy Changes suggested by Michael and Sandy to address bug 5417.
The THEN clause of rule 3a in 6.3.1 lacks a verb: If the component's {base type definition} is a complex type definition, then the {rules} of the {base type definition}. Section 6.3.1 "rule" 2 reads more like a procedural instruction than a (structural) rule.
Marked hasProposal because comment# 3 adds one.
+1 for the proposal with the following editorial suggestions: - change title of 6.3.1 to "Content of {rules} Property" - section 6.3.1, para 2 - change "can be" to "MAY be" - either remove "Rules" from title of sections 6.3.2 and 6.3.3 or replace with "Assessment". The goal is to use rule in section 6 only when referring to schematron constraints. For consistency, we could consider changing other section titles from "Rules" to "Assessment" or to remove "Rules" entirely from the section titles (e.g., in subsections of section 5) - change 1st sentence in 6.3.2 from: Model validators MUST enforce the following rules. to: Model validators MUST enforce the following:
+1 for the changes with following comments: [1] The non-normative note describes an important issue. It points out that schematron constraints in SML do not necessarily come from file-based schema documents. They can be constructed programmatically. However, this is not restricted to schematron constraints in SML. It also applies to other SML constraints such as id constraints or target* constraints. This means that this note should be moved to a more general location and the scope of its content should broadened to include all constraints. [2] The title change is not necessary in view of the comment above. The word 'Schema' does not necessarily imply a schema stored in a file/document. Since schema can be constructed programatically, the title 'Mapping from schema' is not necessarily wrong and does not need to be changed. [3] I agree to the change suggested in comment# 6: 'can be' => 'MAY be'
Resolution in 2/21 meeting: mark editorial (make changes suggested by comment# 3 as ammended by comments #4 to #7. 1 exception: do not change the title 'mapping from schema') No needsReview.
Made changes according to proposal and comments.