W3C home > Mailing lists > Public > public-sml@w3.org > December 2007

[Bug 4644] Allow assertions on local elements and types

From: <bugzilla@wiggum.w3.org>
Date: Thu, 13 Dec 2007 08:50:26 +0000
CC:
To: public-sml@w3.org
Message-Id: <E1J2jly-0002W3-Tg@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4644





------- Comment #5 from kumarp@microsoft.com  2007-12-13 08:50 -------
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 D’s rules can be a subset of B’s 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 Schema’s 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
Received on Thursday, 13 December 2007 08:50:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:56:08 UTC