[
Lists Home |
Date Index |
Thread Index
]
xsi:type is a scab.
If the union of instances agrees to a contract (the schema) with management
(the parser), xsi:type is the badge of the scab.
For example, suppose that a system is designed such that a few thousand
licensed franchisees are going to collect some information, which they are
going to submit (over secured, authenticated links) to a battery of one
hundred validating servers, which in turn all feed into a single process
server. The idea is to offload validation from the main processing server,
but still have control over the input, to guarantee its correctness.
Imagine, then, that a portion of the schema which is to be used for
submission looks like this:
<xs:element name="registrant" minOccurs="1" maxOccurs="1">
<xs:complexContent>
<xs:sequence>
<xs:element name="personalName" type="xs:string" minOccurs="1"
maxOccurs="1" minLength="2" />
<xs:element name="familyName" type="xs:string" minOccurs="1"
maxOccurs="1" minLength="2" />
<!-- more information here, also very strongly typed -->
</xs:sequence>
</xs:complexContent>
</xs:element>
The purpose behind the very strong typing of personalName and familyName is
to enforce appearance, and to ensure that on the heavily loaded processing
server, one can rely upon the previous validation step. This means that it
isn't necessary to code a lot of complex, potentially buggy error-checking;
it's possible to be *certain* that required things are going to appear, in a
certain order, and they won't be empty strings. Validation offers
error-checking. It's expensive, so we expect it to *work*. Right?
And here's an excerpt from a valid instance:
<registrant xsi:type="xs:string">No information provided</registrant>
Bye-bye, error-checking-free server! Runtime failure, for a *valid*
document.
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):
1) xsi:type must always be a "narrowing cast"
2) xsi:type cannot replace a complex type with a simple one
3) xsi:type overrides can be disabled in the parser
But I don't think that they are true, which means that validation is
effectively worthless, because no matter how complex the schema created, I
can always replace it with:
<rootElement xsi:type="xs:string">Neener, neener! Look, ma, I'm
valid!</rootElement>
Even item 1 in the list above doesn't help all that much, given the extreme
oddities of the XSDL type system, in which QName and anyURI are not strings,
date and time are not derivations of dateTime, gYear is unrelated to
gYearMonth, float and double have no relationship to the rest of the number
tree, and so on. It *would* be better than nothing, though, and would
probably help a great deal with complex types.
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.
Amy!
--
Amelia A. Lewis amyzing@talsever.com alicorn@mindspring.com
The one thing you can't trade for your heart's desire is your heart.
-- Miles Vorkosigan
|
