Please see my comment ibn 4643. Recommend that this bug be resolved as Won't Fix

Proposal: resolve this one as "won't fix" as suggested earlier since 4643 was resolved as "won't fix".

I don't think our resolution to bug 4643 can be directly applied here. The reason we believe 4643 should be resolved by allowing inheritance is that schema already inherits types from substitution group (and we thought it should have inherited more). But this one is different. Schema doesn't inherit anything in particle restriction.

For substitution group, because it's very clear what the inheritance source is, it's easier for people to imagine what's expected. For particle restriction, it's not always as clear, when content models become complex. Having this kind of side-effect may sometimes causes surprises.

This also makes it hard (if not impossible) to achieve the same result if a processor chooses to support schema 1.1, where the "matching particle in the base" concept no longer exists (it's possible for the same particle in the derived type to have multiple counterparts in the base).

If we really want this kind of inheritance (and I'm not convinced), we could look at how schema 1.1 handles Type Alternative Table inheritance. They seem to be very similar issues and demand the same kind of solutions.

Created ACTION-149 - Add an example of the problem to the bug [on Sandy Gao - due 2007-11-15].

Example:
1. complex type B1 has local E with targetType="xs:decimal".
2. complex type B2 has local E with targetType="xs:boolean".
3. global group definition G has local E without targetType.
4. complex type R1 derived by restriction from B1 with a reference to G.
5. complex type R2 derived by restriction from B2 with a reference to G.

Question: what's the value for targetType for E in R1 and R2? It should be
"xs:decimal" if inherited from B1, but "xs:boolean" if inherited from B2.

Possible answer:
1. Invalid, because there are multiple inheritance sources.
2. Valid, and introduce rules (similar to schema 1.1 type table) that make
inheritance happen at complex type level, as opposed to particle/element level.

Neither answer sounds particularly attractive. On the other hand, if we say
constraints are *not* inherited through particle restriction, then:
- No need to handle the above case
- It's aligned with XML Schema
  - Schema authors can expect same behavior for schema and sml constraints

Note that "not inheriting" doesn't cause much trouble for schema authors:
- Not much burden to repeat sml:target* constraints (attributes)
- With the "ref" attribute introduced, sml:key/keyref etc. constraints are also
easy to repeat.

Proposal:
SML target* constraints and SML identity constraints are handled as defined below:
1.	Constraint can be specified on global and local element declarations.
2.	Constraint is attached to the element declaration schema component.
3.	If a constraint is present on a particle P in a complex type definition then all of the following must be true:
a.	The constraint must be present on all particles having the same name as P.
b.	The value of all such constraints must be identical.
4.	Each complex type definition CT has the following additional properties attached to the complex type definition schema component. The value of these properties for xs:anyType is empty.
a.	{targetTypeConstraintList}
b.	{targetElementConstraintList}
c.	{targetRequiredConstraintList}
d.	{identityConstraintList}
5.	The value of each property corresponding to constraint C, defined above, can be either empty or a list of (qname, value) pairs. For each such pair,
a.	qname is the name of a particle P within CT 
b.	value is the non-null value of the constraint C on P. 
6.	For a given complex type CT, a property corresponding to constraint C is assigned value V as follows:
a.	If CT is derived by extension from a simple type definition then for each element declaration ED, with name qn, contained  in CT, 
i.	If ED does not have constraint C then skip ED.
ii.	If there is already an entry in V for qn, then skip ED.
iii.	If ED has constraint C defined then add an entry (qn, value of C) to the list V
b.	If CT is derived by extension from a complex type definition BT then the property values are calculated as defined in 7.a and then for each constraint property in BT,
i.	For each entry in the property
1.	If there is a corresponding entry in CT, then ensure that the entry in CT is identical to to that in BT.
2.	Otherwise, copy the entry in BT to the list in CT.
c.	If CT is derived by restriction from base type BT then, the property values are calculated as defined in 7.a. Now, for each constraint property in BT,
i.	For each entry in the property
1.	If there is a corresponding entry in CT, then ensure that the entry in CT is correct restriction of that in BT. In case of identity constraint, the entries must be identical. Two identity constraints are considered identical if they have the same qname.
2.	If there is no corresponding entry in CT then copy the entry in BT to the list in CT.
7.	Validation: If element P has type CT and has child C then, the appropriate entries from {*ConstrainList} properties are used for validating C.

The proposal in comment #6 mentions "particle" many times. It should actually be "element declarations" that are "contained" in the complex type. This change covers cases where substitution groups are involved.

If a substitution group head is contained in a complex type, then the members are also "implicitly" contained. These implicitly contained element declarations should also contribute to {*ConstrainList}.

I agree with comment# 7.

Updated the proposal to use element declarations instead of particles as suggested in comment# 7.
--------------

SML target* constraints and SML identity constraints are handled as defined below:
1.	Constraint can be specified on global and local element declarations.
2.	Constraint is attached to the element declaration schema component.
3.	If a constraint is present on an element declaration ED contained (directly, indirectly or implicitly) in a complex type definition CT then all of the following must be true:
a.	The constraint must be present on all element declarations having the same name as ED.
b.	The value of all such constraints must be identical.
4.	Each complex type definition CT has the following additional properties attached to the complex type definition schema component. The value of these properties for xs:anyType is empty.
a.	{targetTypeConstraintList}
b.	{targetElementConstraintList}
c.	{targetRequiredConstraintList}
d.	{identityConstraintList}
5.	The value of each property corresponding to constraint C, defined above, can be either empty or a list of (qname, value) pairs. For each such pair,
a.	qname is the name of an element declaration ED within CT 
b.	value is the non-null value of the constraint C on ED. 
6.	For a given complex type CT, a property corresponding to constraint C is assigned value V as follows:
a.	If CT is derived by extension from a simple type definition then for each element declaration ED, with name qn, contained  in CT, 
i.	If ED does not have constraint C then skip ED.
ii.	If there is already an entry in V for qn, then skip ED.
iii.	If ED has constraint C defined then add an entry (qn, value of C) to the list V
b.	If CT is derived by extension from a complex type definition BT then the property values are calculated as defined in 6.a and then for each constraint property in BT,
i.	For each entry in the property
1.	If there is a corresponding entry in CT, then ensure that the entry in CT is identical to to that in BT.
2.	Otherwise, copy the entry in BT to the list in CT.
c.	If CT is derived by restriction from base type BT then, the property values are calculated as defined in 6.a. Now, for each constraint property in BT,
i.	For each entry in the property
1.	If there is a corresponding entry in CT, then ensure that the entry in CT is correct restriction of that in BT. In case of identity constraint, the entries must be identical. Two identity constraints are considered identical if they have the same qname.
2.	If there is no corresponding entry in CT then copy the entry in BT to the list in CT.
7.	Validation: If element P has type CT and has child C then, the appropriate entries from {*ConstrainList} properties are used for validating C.

resolution in conf call on 1/10: proposal accepted as stated in comment# 9

Created attachment 512 [details]
Diff for the fix

Contains sml-diff.html

Fixed and attached sml-diff.html (inside sml-diff.zip) that shows the changes made.

Sorry for the belated comments.

1. Section 5.1.2.1 (old 4.4.2.1), all "c" bullets should now be removed.

Our 5063 resolution is essentially: target* are inherited through new properties on complex types, and NOT on elements inside the restriction types.

2. Section 5.1.2.2 (old 4.4.2.2), bullet 3 needs to be removed.

It should be allowed for EB to have target* and ED to not have them (in which case complex type inheritance takes effect). The restriction requirements should be enforce on the complex types, not the elements. (See below #7.)

3. #1 and #2 also apply to identity constraints: section 5.2.1.1 (old 4.5.1.1, the last paragraph should be removed) and section 5.2.1.2 (old 4.5.1.2, delete bullet 13).

4. Section 5.3.2.1, should be more precise about "the name of an element declaration". {name} of element declarations is only the local part. We need both that and the namespace.

5. Same section, the descriptions are not precise. When target* are inherited, the value of {target * constraint list} may correspond to element declarations in the base type, and not those contained in the current complex type.

6. To be consistent 5.3.2.2 title should be "mapping from schema".

7. Bullet 3.a in 5.3.2.2, need to be explicit about what "is a valid restriction" mean. Either repeat the rules or refer to the relevant sections (5.1.2.2 and 5.2.1.2).

8. Need to introduce complex type validation rules (e.g. 5.3.2.3 Instance Validity Rules) that enforce {target * constraint list} properties. Something like: if E is an instance of CTD, C is a child of E, and C matches an element declaration contained in CTD, and CTD's {target * list} has a value for C's name, then the corresponding target* constraint is check for C, in a way similar to what's defined in 5.1.2.3 and 5.2.1.3.

Note that it's important to say "C matches an element declaration contained in CTD" and not "C's name matches a member in the {target * list}", because C may match a wildcard and a global element declaration which has a different target* constraint.

One more.

9. It seems the following was not implemented:

"The value of these properties for xs:anyType is empty."

All of the changes suggested in comment# 13 and comment# 14 applied.

Created attachment 520 [details]
comment-15

Attached sml-diff-2.html, inside sml-diff-2.zip, that shows the changes applied as part of comment# 15.

This is significant improvement. A few additional comments:

1. Nested MUST. In 5.3, "... MUST be true: 1. ... MUST be true".

Schema 1.0 had similar problems and 1.1 only uses MUST at the top level and use is/are in the sub-bullets.

2. The new section 5.3, bullet 1 has "one of the following MUST be true". This is not correct: bullet (b) is always true, then (1) is always true. There are 2 ways to fix it.

The easy fix is to replace "one of the following" with "the appropriate case among the following" (this is how the schema spec handles similar rules).

Alternatively (which I prefer) is to use words that were in 5.1.2.2. That is

   1. For {target required}, if BV is true, RV is true.

I would also prefer to collapse (a) and (b) in (2) and (3) to use the original 5.1.2.2 wording, but can live with the current formulation.

Note that 2.a is redundant, because it's covered by 2.b. (Global elements are in their own substitution groups.)

3. The new section 5.4.2.3 refers to 5.1.2.3 and 5.2.1.3 for validation rules. Those sections expect {target*} on element declaration, but here we are getting values from the complex types.

Maybe we can add in 5.4.2.3 "as if the matching element declaration has the corresponding constraint with that vaue", to fix this disconnection.

Fix per comment #17.

[1]
Fixed as suggested.

[2]
Used the appropriate case among the following applies as suggested.

I did not use the previous wording of bullet 1 because it leaves the BV is false case implicit. I wanted to define both cases explicitly. Also, I have left the current sub-bullet structure (a & b) instead of the previous wording because of similar reasons. 

[3]
Fixed as suggested.

[4]
Added clarification-type changes to 5.4.2.2 as discussed.