Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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
|
