[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] xsi:type and broken contracts
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@t... alicorn@m... The one thing you can't trade for your heart's desire is your heart. -- Miles Vorkosigan
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|