Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: xsi:type and broken contracts
<snip/>
>>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.<<
I have been using xsi:type in documents for a long time now-- in my apps I
consistently am serializing objects to XML and back. I chose to use xsi:type
to control type information and have had nothing but success with it.
<TObject xsi:type="obj:TFooObject">
<TObject xsi:type="obj:TBarObject">
<bar1>Bar Property 1</bar1>
</TObject>
<foo1>Foo Property 1</foo1>
</TObject>
Right now I can do a match on the xsi:type attribute, but matching the type
might be better. With the above you can easily use type substitution exactly
as you would in OOP. If I declare in my XML Schema that TObjects may contain
unbounded child TObjects then I can nest any datatypes and traverse them
easily. I know folks here say all the time that object serialization is most
horrible idea ever-- but it works, is cross-platform, and allows interop
that can be validated using any XML Schema validator. It's true that I could
use other schema languages to do the same thing (and I am planning to...)--
the point is that it is working now.
-Jeff Rafter
|
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
|
|||||||||
