This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5417 - inconsistent lists of constructs where rules are supported
Summary: inconsistent lists of constructs where rules are supported
Alias: None
Product: SML
Classification: Unclassified
Component: Core (show other bugs)
Version: LC
Hardware: PC Windows XP
: P2 normal
Target Milestone: LC
Assignee: James Lynn
QA Contact: SML Working Group discussion list
Depends on:
Reported: 2008-01-25 01:21 UTC by John Arwe
Modified: 2008-02-22 15:54 UTC (History)
0 users

See Also:

Changes suggested by Michael and Sandy (38.16 KB, text/html)
2008-02-15 15:24 UTC, Sandy Gao

Description John Arwe 2008-01-25 01:21:21 UTC
(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."
Comment 1 Valentina Popescu 2008-01-31 20:44:49 UTC
01/31 meeting resolution to mark bug as needsAgreement

actions opened to come up with proposals
Comment 2 C. M. Sperberg-McQueen 2008-02-14 18:56:06 UTC
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.)
Comment 3 Sandy Gao 2008-02-15 15:24:29 UTC
Created attachment 521 [details]
Changes suggested by Michael and Sandy

Changes suggested by Michael and Sandy to address bug 5417.
Comment 4 Kirk Wilson 2008-02-16 20:20:00 UTC
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.
Comment 5 Kumar Pandit 2008-02-19 06:29:53 UTC
Marked hasProposal because comment# 3 adds one.
Comment 6 Virginia Smith 2008-02-19 18:34:36 UTC
+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.


Model validators  MUST enforce the following:
Comment 7 Kumar Pandit 2008-02-19 21:48:23 UTC
+1 for the changes with following comments:

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. 

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.

I agree to the change suggested in comment# 6: 'can be' => 'MAY be'
Comment 8 Virginia Smith 2008-02-21 20:28:41 UTC
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.
Comment 9 James Lynn 2008-02-22 15:54:08 UTC
Made changes according to proposal and comments.