Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] The Two Poles of the XML World (was RE: W3C's five new XQuery
 > -----Original Message----- > From: Paul T [mailto:pault12@p...] > Sent: Sunday, December 30, 2001 2:16 AM > To: Jonathan Robie; Champion, Mike; xml-dev@l... > Subject: Re: W3C's five new XQuery/Xpath2 working drafts - > Still missing Updates > > During validation, wouldn't you like the xml processor to notice that the > > given text is not a valid birthdate? > > > Bringing types to XML, ( based on 'it looks like' ) would bring > plenty of madness. And the service, provided by that validation layer > is virtually not-existant. People, who do not validate their data for > consistency before placing the data into the database can not be > saved with a complex ( XSD is complex ) layer that 'helps' them, This thread very clearly illustrates that there are polar opposite ways of thinking about how to use XML in software applications. Most of us probably live and work in the temperate zone between them, but I think it's useful to keep in mind what the ideal types at each pole look like, and to lay out decision rules for when one might gravitate toward one pole or the other. Or maybe I've projected some orthogonal dimensions onto one, so it might be fruitful to discuss other dimensions and what their "poles" look like ... but let me get the ball rolling by describing the two poles that I see -- Strongly typed, centralized, query-oriented: "Do the right thing"; design complex applications up front and use rigorous engineering techniques to make everything work right. Strongly typed XML views or repositories can be a "hub" connecting disparate databases, programming objects, and XML documents to application developers, and these developers can use an XML type system to catch data and programming errors early in the process. To provide the tools powerful enough to do all this, it is critical for the W3C to develop specs such as XSD and XQuery that incorporate the cutting edge of the relevant academic theories and research lab experiments. Loosely typed, loosely coupled, flow-oriented: "Interesting emergent properties evolve"; grow complex systems from simple components and use "gardening" techniques to kill off the bugs and weeds and rigorously prune unwanted tendrils. XML is just "smart text", putting the information into XML format simply allows us to "pipe" it between decoupled processes that use XML tools look for patterns in the messages, insert new information in the messages, and/or transform the messages to add value for some downstream process or user. To provide the most generally useful and reliable tools to do all this, the W3C (or some other standards organization) should focus on making individual specs as simple, solid, and modular as possible, continually incorporating feedback from the field to correct and clarify the specs. I would not begin to argue that one pole is "better" than the other. XML owes a lot to both SGML (clearly a tool that favors up-front design, insists on defined "document types", and generally worked best in tightly coupled systems) and the Web (where surprising things happened when simple, modular, loosely coupled components were connected and used in unanticipated ways). Likewise, my employer very definitely supports both poles, from strongly-typed XQuery to our EntireX Orchestrator dataflow transformation/routing product with an "emerger" component to help bring emergent properties to the surface. So, what might the decision tree to steer someone to the "strong" pole or the "loose" pole look like? I'll just throw out a few criteria that would tend to point in one direction or the other, and maybe others can add to or critique them: Are your requirements and environments predictable and stable? -> strong Is everything changing faster than you can cope? -> loose Is it most important to know your system is correct? -> strong Is it most important to know your system is flexible? -> loose Are you importing/exporting strongly typed data? -> strong Are you importing/exporting loosely structured data? -> loose Can you reject input data that is not schema valid? -> strong Can you ignore input data that you don't understand? -> loose Are you developing with Java or C++/C#? -> strong Are you developing with script or VB? -> loose Do you think you should "Do the Right Thing?" no matter what? -> strong Do you (maybe reluctantly) accept that "Worse is Better" -> loose Do you have authority to make others do the right thing? -> strong Are you at the mercy of folks who live by Murphy's Law? -> loose The less easily resolved problem made clear in the recent thread is simply that the W3C has finite resources. It can't simultaneously incorporate the cutting edge stuff from academia in ever more powerful specs on one hand, and iteratively standardize and clean up simple best practice from industry on the other. I'm not so sure I have a decision tree for handling that ... 
|
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
|
|||||||||
