This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We have previously discussed why SML does not define rule bindings for schema components other than GEDs and GTDs, e.g. for local type definitions. There is language in (LC draft) 6.3 Rules Associated with Schema Components that seems to make a stronger statement than the intent above, however. It seems to state that an SML model becomes invalid if rules are attached to places other than GEDs/GTDs. This would prevent another spec, or a later version of SML with additional use cases, from both defining rules on other schema components and remaining an evolutionary, incremental extension of SML 1.1. Allowing incremental evolution would seem to be a better position to protect adopters' investments. Specifically: 6.3.1 Mapping from schema, para 2 "sch:schema elements MAY 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." The final sentence could as easily say that SML 1.1 assigns no meaning to that case, but the LC draft specifically prohibits it. 6.3.2 Schema Validity Rules bullet 1 (similar structure, "close but not same" issue) "The value of {rules} MAY be empty for global element declarations, global complex type definitions or anonymous complex type definition of global element declarations. It MUST be empty for any other schema component." Assuming we decided not to prohibit future extensions of the type this bug posits, final sentence would likely change. E.g. the Mapping from Schema rules might be defined in such a way that the final sentence would be true, so it could change from a normative stmt to a non-normative stmt of consequence or be removed entirely. 6.3.2 Schema Validity Rules bullet 3 "If a complex type D is derived by restriction from {base type definition} B then, a global element declaration with non-empty {rules} contained in B cannot be restricted to a local element declaration in D." Ditto. E.g. this behavior could in effect become: impl-defined, since SML does not define {rules} for local types. SML validators MAY report this as an error.
I found the earlier discussion that Sandy vaguely remembered having on last week's call. It was at the Jan 2008 F2F, and in http://www.w3.org/Bugs/Public/show_bug.cgi?id=5417 One thing I see in this discussion is that the proposal http://www.w3.org/Bugs/Public/attachment.cgi?id=521&action=view , eventually adopted with modifications, appears to NOT address all of the 5417's original points. At best, it partially addresses point 3. We got side-tracked onto different, but still valid, issues when discussing 5417. This discussion fundamentally has 2 prongs: Prong 1: Consistency in the text about where SML intends to allow rule attachment. My sense from working group discussions of its intent to define rule attachment for each of the following: P1a - GEDs: yes (pretty clear) P1b - GTDs: yes (pretty clear) P1c - Local EDs: no (pretty clear) P1d - Local TDs: no (pretty clear) P1e - Anonymous TD as a child of a GED: not sure P1f - Restriction from GED with rules attached to a Local ED: no (pretty clear) Note that P1e is mentioned explicitly in at least one place, both before and after 5417 was fixed, namely (LC draft) 6.3.2 bullet 1. For this prong, the following changes would be needed if the bullets above are indeed the intent of the working group: Prong 1 change 1: 6.3 Rules Associated with Schema Components from: SML defines a new property for every complex type definition schema to: SML defines a new property for every global complex type definition schema from: component and every element declaration schema component. to: component and every global element declaration schema component. Need to add P1e if that case is intended to be covered too. Prong 1 change 2: 6.3.1 Mapping from schema, paragraph 2 Need to add P1e if that case is intended to be covered too. We likely should be clearer that "embed" here means as a first child of appinfo. If someone created components equivalent to appinfo/ackbar/sch:schema I get the impression that the wg would not expect those to be processed by SML. Prong 1 change 3: 6.3.1 Mapping from schema, paragraph 3 Add to end: The local-rules of all other schema components is the empty set. This could also be accomplished by adding a new bullet 4 to the list as an Otherwise. Need to add P1e to first sentence if that case is intended to be covered too. Prong 1 change 4: 6.3.1 Mapping from schema, bullet 3 from: If the schema component is a complex type definition to : If the schema component is a global complex type definition Need to add P1e to first sentence if that case is intended to be covered too. Prong 1 change 4: 6.3.1 Mapping from schema, bullet 3.a from: component's {base type definition} is a complex type definition to: component's {base type definition} is a global complex type definition Need to add P1e to first sentence if that case is intended to be covered too. Prong 1 change 5: 6.3.2 Schema Validity Rules, bullet 1 If P1e is intended to be covered, leave as is; else, remove it from existing text. Prong 1 change 5: 6.3.2 Schema Validity Rules, bullet 2 from: If a complex type D is derived to: If a global complex type D is derived Prong 1 change 6: 6.3.2 Schema Validity Rules, bullet 2 from: from {base type definition} B to: from global {base type definition} B Prong 1 change 7: If P1e is intended to be covered too, may need new bullets corresponding to 6.3.2 Schema Validity Rules, bullets 2 and 3. Prong 1 change 8: 6.3.3 Instance Validity Rules, bullet 1 from: in {rules} of a complex-type definition CT to : in {rules} of a global complex-type definition CT ----------------------------------------- Prong 2: Whether or not the working group intends to make it intentionally difficult to define rules on the "no" cases amongst P1a-P1f in other specs that would perhaps layer on top of SML 1.1. On the 4/10 call, the subset of the working group ready to express an opinion leaned away from interfering with other specs covering cases for rule attachment that SML 1.1 does not cover (e.g. P1c, P1d). If that represents the intent of the working group, then the following changes are suggested. Prong 2 change 1: 6.3.1 Mapping from schema, paragraph 2 from: They MUST NOT be embedded in any other kind of schema component. to : SML assigns no meaning to them and stipulates no requirements on their processing if they are embedded elsewhere. Prong 2 change 2: (possibly optional, have not fully convinced myself yet) 6.3.1 Mapping from schema, paragraph 3 Add to end: The local-rules of all other schema components is the empty set. This could also be accomplished by adding a new bullet 4 to the list as an Otherwise. Prong 2 change 3: 6.3.2 Schema Validity Rules, bullet 1 Remove: It MUST be empty for any other schema component. Alternative to removal (I think it would be easy for readers of the spec to infer that we are actively preventing other specs from defining rule attachment beyond that specified in SML 1.1, regardless of our actual intent): from: It MUST be empty for any other schema component. to: It is a consequence of [6.3.1] that SML will not contribute to {rules} for any other schema components. Prong 2 change 3: 6.3.2 Schema Validity Rules, bullet 3 from: cannot be restricted to a local element declaration in D. to : cannot be restricted to a local element declaration in D without loss of the {rules} contributed by B. This case SHOULD be reported, and MAY be treated as an error. Prong 2 change 4: 6.3.2 Schema Validity Rules, bullet 3 note from: It is an error if all to : It is very likely an error if all Prong 2 change 5: 6.3.2 Schema Validity Rules, bullet 3 note Append to the non-list sentence: SML allows validators to accept this case as valid in order to allow future specifications to compatibly layer on top of SML. Such specifications may define rule attachment for constructs such as local type declarations not covered in this version of SML. SML does not wish to automatically force models compliant with such future specifications to be declared invalid with respect to SML.
I'm not sure how P1d and P1e are intended to relate. P1d - Local TDs: no (pretty clear) P1e - Anonymous TD as a child of a GED: not sure If comment #1 intends them to be disjoint cases, we have a problem. The set of local type definitions and the set of anonymous type definitions are the same set. If comment #1 intends P1e as a subset of P1d (those local = anonymous type definitions which are local to global element declarations), then there's no contradiction but I was confused. In figuring out what we want to do on P1e, we should probably make sure we are all on the same page as to what set of things we are deciding about.
(f2f discussion) The relationship intended is that P1d = local type defs EXCEPT those in P1e (i.e., EXCEPT for anonymous type defs with GED parents). The reason that anonymous type defs must be allowed to have non-empty rules is to deal with substitution groups, as in the following example. Given: - element E1, of type T1 - element E2, substitutable for E1, with an anonymous type definition (that we call T2 in this bug, but it has no name="T2" value since it is anonymous) Existing SML requirements for rule attachment allow T1 to have rules since it is a GTD. Since E2 is substitutable for E1, T2 must be a derivation of T1. Since SML forces inheritance of rules, it must require that T2 inherits any rules attached to T1.
(f2f consensus) - prong 2 change 1 (removal of general prohibition of rules on locals) accepted in concept - Prong 2 change 2: conceptually yes, with changes below - prong 2 change 3 ...second change 3 NOT accepted, keep this restriction prong 2 change 1: want reasonable reader to understand that if {rules} is non-empty on a component for which sml assigns no meaning, those {rules} have no effect on sml validity. prong 2 change 1: editorial sugg, replace "elsewhere" with "in any other kind of schema component" Prong 2 change 2: add item 4 to 6.3.1 "otherwise the value of {rules} is not defined" Prong 2 change 3 (first change 3): 6.3.2 Schema Validity Rules, remove bullet 1 entirely prong 2 change 3 (second change 3) NOT accepted, keep this restriction Prong 2 change 4: NOT accepted Prong 2 change 5: NOT accepted
Prong 1 change 1: REJECTED Prong 1 change 2: Desire to define what embed means, but not as children since we are talking about schema properties here. from: sch:schema elements MAY be embedded in members of the {application information} of the .. to: sch:schema elements MAY appear as items in the {application information} of the ... Prong 1 change 3: dup of prong 2 change 2 Prong 1 change 4 (first one): REJECTED, otherwise it would not covers P1e Prong 1 change 4 (second one): REJECTED as harmless & potentially confusing Prong 1 change 5 (first one): NO CHANGE, since covering p1e is desired Prong 1 change 5 (second one): REJECTED, so p1e is covered Prong 1 change 6: REJECTED, harmless but unnecessary Prong 1 change 7: REJECTED, unnecessary due to other changes rejected above Prong 1 change 8: REJECTED MSM proposal: Add to 6.3.1 Mapping from schema, paragraph 3: For other schema components, local-rules is empty. MSM proposal is ACCEPTED. The wg members ARE aware that the MSM proposal = prong 1 change 3 = prong 2 change 4, we simply read 2/2 incorrectly the first time around.
Fixed per comment #4 and comment #5. See diff at: http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.227%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&doc2=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.229%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1 The differences are in 6.3.1 and 6.3.2 only. Ignore other changes in the diff - they resulted from the build and were unintentional. Note that the MSM proposal that is stated as "accepted" in comment #5 conflicts with Proposal for prong 2 change 2 in comment #4. The change was made per comment #4.
f2f consensus is to accept the changes with the following revisions: Add to 6.3.1 Mapping from schema, paragraph 3: For other schema components, local-rules is empty. change new item 4: Otherwise, the value of the {rules} property is not affected by this specification. chg to 6.3.1 parag 2: This specification assigns no meaning to sch:schema elements if they appear as items in any other location. please make needsreview again once these changes have been made.
Fixed per comment #7. See diff at: http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.234%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&doc2=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.235%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1
Per resolution in 8/7 call