[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: bohemians, gentry
Jonathan Robie wrote: > > At 12:45 PM 12/4/2002 -0500, W. E. Perry wrote: > > > >AOL to this, Uche. > > > >I would actually go beyond your point: > > > >"Certainly, if you want your data to outlast your code, and to be more > >portable to unforeseen, future uses, you would do well to lower your own > >level of class consciousness. Strong data typing in XML tends to pigeonhole > >data to specific tools, environments and situations. This often raises the > >total cost of managing that data." > > > >It is not just over time, but right now, between utterly dissimilar systems > >whose only nexus is the internetwork, that communication is possible only by > >instantiating a common syntax into locally idiosyncratic semantics at each > >end of the conversation. > > I still don't understand this point. Could someone please illustrate with > an example that uses several kinds of software processing data that uses > datatypes, and showing how the presence of datatypes in that data prevents > it from being used except in "specific tools, environments, and situations"? The way I see it, the problem is not XML annotated with data types _per se_; rather it's the assumption by schema designers that those data types will be available to all processes. If the designer isn't careful, this assumption can easily lead to document types that can only be processed by WXS-aware tools. Jonathan has asked (repeatedly) for concrete examples of how typed XML causes interop problems. I don't have any such examples since I haven't made that _particular_ mistake; but in the general theme of overreliance on schema information I've goofed many times. For instance: I used to be a big fan of keying processing off of #FIXED attributes in the DTD. This worked really well in the SGML world, but with XML it limits you to using DTD-aware processors (and making sure they can find the DTD, even when disconnected from the Web, et cetera.) This led to so many headaches that I now use different techniques to do architectural forms. Lesson learned. It seems to me that the "International Purchase Order" schema in section 4 of the W3C XML Schema Primer [1] comes close to the edge of that slippery slope. While _most_ of it can be processed by WXS-oblivious tools, there are some tasks that can't be done (or can't be done easily) without a type-annotated PSVI and full schema information. For instance: write a program that extracts all of the comments from a purchase order (see the schema fragment in section 4.6), Now you could do this with an XSL transform that extracted all the 'ipo:shipComment' and 'ipo:customerComment' elements (since those are the only two elements defined to be of that type), but that's fragile; if the schema is extended to include other comment types, the transform will silently break. Or similarly, find all the Vehicles in a document conforming to the schema in section 4.7. Or just about any of the tasks in section 1.9 of the W3C XML Query Use Cases document [2] -- because of the way the schema is designed, XQuery is probably the *only* tool that can perform these tasks. But the key issue is: if you want your data to outlast your code, don't encode it in a way that's too tightly bound to any particular process. Peeking at data types in the PSVI to make processing easier is not necessarily a problem; schema designs that *require* processes to do so are. This is just one instance of the general theme. [1] <URL: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.html#IPO > [2] <URL: http://www.w3.org/TR/xmlquery-use-cases/#strong > --Joe English jenglish@f...
|
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
|