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

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 
set."

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.

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



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

To
public-sml@w3.org
cc

Subject
[Bug 4644] Allow assertions on local elements and types







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