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

Re: [Bug 4644] Allow assertions on local elements and types

From: Sandy Gao <sandygao@ca.ibm.com>
Date: Thu, 13 Dec 2007 12:29:14 -0500
To: public-sml@w3.org
Message-ID: <OFBF7FE883.985051CB-ON852573B0.005FBB02-852573B0.00600F83@ca.ibm.com>
Again having trouble accessing Bugzilla...

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 

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.

Sandy Gao
XML Technologies, IBM Canada
Editor, W3C XML Schema WG
Member, W3C SML WG
(1-905) 413-3255 T/L 313-3255

Sent by: public-sml-request@w3.org
2007-12-13 03:50 AM


[Bug 4644] Allow assertions on local elements and types


------- 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 
model validation together with the specified message.  Model validation 
evaluate each Schematron pattern for all of its applicable elements 
in the model." 
which is now covered in Suggest to remove it from 5.0. 
[kumarp] done. The first sentence was moved to since it was not 
covered by that section. The second sentence was deleted.
2. Suggest to change the title of 5.2 to "Rules Embedded in Schema 
[kumarp] done
3. Suggest to remove 5.2.1 and put its content in 5.2. (Note that there is 
[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 
should really be "a set of Schematron schemas"? 

[kumarp] I like the word ?constraint? because it also aligns with other 
of the spec (ref constraints, identity constraints, etc.). However, I 
that we should consistently use the same word, therefore I defined it in 
Terminology section as:
Schematron Constraint
The information contained within a single sch:schema element.
I referenced this definition where appropriate for consistency.

5. Section "It MUST NOT be attached to any other kind of schema

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 
was that, for anonymous types, Schematron rules are not allowed at the 
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 
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". 
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 to clarify that the 
sentence only applies to the syntax. If we go with this route, we can 
the first paragraph in to: 

"sch:schema elements can be embedded in members of the {application
information} of the {annotation} of a global element declaration or a 
complex type definition. They MUST NOT be embedded in any other kind of 

This fits better in section, because this section is about syntax 
model mapping, so constraints should be described in terms of the syntax. 
[kumarp] done.

5. Section, 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 
have 2 different cases: if base is complex, then union; otherwise use
[kumarp] done.

7., bullet 1. This again contradicts our decision that anonymous
complex types can have rules via inheritance. This rule should only apply 
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, 
they must have the same {target*/identity constraints}". Do we want the 
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 
and they are both contained (directly, indirectly, or implicitly) in a 
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 
cannot be included in the same complex type definition as a local element
[kumarp] Please see the earlier comment. Defining ?same set of rules? is 

9., bullet 2.a. The "automatically copied" rule is already covered 
in bullet 4. What we should say in, if anything, should be 

"If complex type definition D is derived from another complex type 
B, then D'{rules} is a super set of B's {rules}." 
[kumarp] Since we automatically copy rules from base type to the derived 
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 
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 
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 
the union of {rules} is performed by the SML validator or by schema author 

9., bullet 2.b.iii. -> "EB is a global element declaration ..." 

10., bullet 2.b. The reason the case described in 2.b is an error 
because it violates the "restriction" rule, which is not clear from all 
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 
see Schema Component Constraint: Particle Valid (Restriction), Constraints 
Particle Schema Components in [XML Schema Structures]), then {rules} of ED 
be a superset of that of EB. 

Note: this implies that if a global element declaration with non-empty 
is included in a base type definition, then it cannot be restricted to a 
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 
word ?superset? and still achieve the end result.

11. See comment 4. Depending on what {rules} contains (set of schemas,
patterns, constraints, rules, assertions, ...), needs to be 

12. 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 
2. Each Schematron schema/pattern/constraint in {rules} of a global 
declaration ED MUST be evaluated for all element instances of G in a 
3. As defined in the Schematron specification [ISO/IEC 19757-3], a 
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 
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 
section can be combined with 5.1.
[kumarp] done
Received on Thursday, 13 December 2007 17:29:31 UTC

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