RE: [xml-dev] xsi:type and broken contracts

["Dare Obasanjo" <dareo@microsoft.com>]

I think Jeni did a good job clearing up your misconceptions. However
there is one problem with xsi:type which has been bothering me for the
past couple of days. The xsi:type screws up the kind of type aware
processing that will be enabled with XQuery and XSLT. 

With XQuery and XSLT one can attempt to process elements based on their
XSD types but with xsi:type one can both restrict and extend these types
in the instance document unbeknownst to the author of the processing
code. At first glance it seems like both these mechanisms do not
radically alter the content model in such a manner that carefully
written type aware processors will be rendered ineffective. 

However until applications start getting built there probably is no sure
way to tell if my fears are unfounded or not. 

-- 
PITHY WORDS OF WISDOM 
Work smarder and not harder and be careful of yor speling. 

This posting is provided "AS IS" with no warranties, and confers no
rights. 



> -----Original Message-----
> From: Amelia A Lewis [mailto:amyzing@talsever.com] 
> Sent: Friday, June 07, 2002 9:54 AM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] 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@talsever.com      alicorn@mindspring.com
> The one thing you can't trade for your heart's desire is your heart.
> 		-- Miles Vorkosigan
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 
<http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>