Digging through section 6.2.1 / multiple types for an element

I've been digging into section 6.2.1 to figure out exactly how to
handle an element with mutiple type definitions on it (ie. schema,
xsi:type, bind type="").

My conclusion is that multiple schema types must have a "natural
inheritance hierachy". So if type X is associated to the element by
schema, and type Y is associated by bind type="", type Y needs to be
derived from type X. This might have been obvious to everyone else but
me, but I thought I'd share my "findings":

For XForms we define the type order in section 6.2.1:
"1) An XML Schema associated with the instance data.
2) An XML Schema xsi:type attribute in the instance data.
3) An XForms type constraint associated with the instance data node
using XForms binding."**
[http://www.w3.org/TR/2006/REC-xforms-20060314/slice6.html#model-using-atomic]

How schema associated types and xsi:type interact naturally belongs in
schema-land, and in section 6.1.1 we define the behaviour of bind
type="":
"The effect of this model item property is the same as placing
attribute xsi:type on the instance data."
[http://www.w3.org/TR/2006/REC-xforms-20060314/slice6.html#model-prop-type]

So how bind type="" mixes with other types also belongs in schema
land, which says:
"1.2.1.2.4 If there is also a processor-stipulated type definition,
the ·local type definition· must be validly derived from that type
definition given its {prohibited substitutions}, as defined in Type
Derivation OK (Complex) (§3.4.6) (if it is a complex type definition),
or given the empty set, as defined in Type Derivation OK (Simple)
(§3.14.6) (if it is a simple type definition)."
[http://www.w3.org/TR/xmlschema-1/#cvc-elt]

** One can argue what exactly is meant by the introduction to the order though:
"The set of facets associated with a model item must be determined by
the following list, as if it were processed in the given order. When
multiple datatype restrictions apply to the same model item, the
combination of all given restrictions must apply."
But if my conclusion does not hold, then there is something wrong in
section 6.1.1 (at least).

--
... Allan

Received on Wednesday, 5 April 2006 11:09:54 UTC