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

Kumar/all,

I'm having trouble accessing Bugzilla. Sending the following comments in 
email. Will post a link to this email into the bug later.

**********

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.

2. Suggest to change the title of 5.2 to "Rules Embedded in Schema 
*Documents*"

3. Suggest to remove 5.2.1 and put its content in 5.2. (Note that there is 
no 5.2.2.)

4. Need to be consistent *Schematron* vs. *schematron*.

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"?

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.

5. Section 5.2.1.1, bullet 2. Simple type definitions don't have {rules}. 
Should remove this bullet.

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.

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

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:

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

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

Also note that this should apply to both restriction and extension. (i.e. 
extension can't remove {rules}.) This should become bullet 2.

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

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

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.

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-12 03:37 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


kumarp@microsoft.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|editorial                   |needsReview




------- Comment #3 from kumarp@microsoft.com  2007-12-12 08:37 -------
The fix involves a large number changes, rearrangement and separation of
normative/non-normative content within chapter 5. Rules.

Please refer to the updated spec for reviewing the changes.