[
Lists Home |
Date Index |
Thread Index
]
> I hope that my understanding is incorrect, and someone can point out that
> one or more of the following are true (or that there is some other saving
> grace somewhere in the system):
I think it is. The functionality of xsi:type is based on the type
substitution model within XML Schema. You can only replace a type with a
derived type (or in the datatypes spec with a derived type or atomic type
from a union). This is within all three schema documents but I will quote
from the primer:
"the processor then examines the type of the element, either as given by the
declaration in the schema, or by an xsi:type attribute in the instance. If
the latter, the instance type must be an allowed substitution for the type
given in the schema; what is allowed is controlled by the block attribute in
the element declaration."
> 1) xsi:type must always be a "narrowing cast"
If you mean "derived type" then yes.
> 2) xsi:type cannot replace a complex type with a simple one
Depends on the method of derivation-- supposing you created an extension of
a simple type to complex type (e.g. to add attributes) then this would be
possible.
> 3) xsi:type overrides can be disabled in the parser
Good idea-- I haven't seen this though.
> But in the presence of xsi:type, I don't see much to value in the strong
> typing of XSDL, even if the type collections collection were made
> systematic.
It is quite the contrary. On top of this XS does allow you to limit the
usability of xsi:type which many people are overlooking here. You can change
the block attribute on an element/type in order to disallow substitution
altogether. Someone could still have the xsi:type attribute but it would be
worthless if there were no allowed substitutions at that point. If someone
counters with "Well we lose one feature (substitution groups) because we
turn off another (xsi:type)" I would argue that it is the same feature.
Jeff Rafter
|
