[Bug 5063] Inheritance of some SML reference constraints

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





------- Comment #9 from kumarp@microsoft.com  2008-01-10 04:11 -------
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.

Received on Thursday, 10 January 2008 04:11:38 UTC