Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Web Design Principles (was Re: GeneralityofHTTP)
 1/29/2002 1:21:09 AM, "Simon St.Laurent" <simonstl@s...> wrote: > >Right now I'm simply depressed that most >developers refuse to take note >of the possibility that XML opens >up _different_ opportunities from what >they're used to, and continue to march down the same data processing >paths they've followed blindly for the last thirty years. Could you elaborate, Simon? Perhaps this gets at the idea: The "conventional" data processing and document processing approach treats XML as simply a standardized input and output format for objects and programs. SOAP was clearly designed primarily as a neutral wire format for serialized object exchange, and the W3C XML Schema spec seems driven more by the needs of RDBMS vendors to exchange SQL data. This is less obviously true for "documents" than "data," but at least the high-end products seem more like they are integrated authoring/publishing tools that happen to use XML as a data format than XML-centric products. In the conventional world, one extremely important criterion is that the XML is a "valid" representation of the internal state of the object or program at the time of serialization. I like to think of the alternative as the "native XML" approach, or perhaps the "XML centric" rather than "object-centric" approach: XML documents (or messages) are at the center of the architecture, not the periphery. The main criterion is whether a well-formed XML instance contains the information needed to push along your business process. To use our favorite example of an order form, some XML message would represent a concrete instance of an "order" in a business process rather than a serialization of an order object in some software program. Just as human clerks can (either instinctively or by training) handle all sorts of diverse order forms so long as they contain the necessary information, an XML-centric "pipeline" (very much in Sean McGrath's sense) could be setup to use a combination of procedural code, XPath/Xquery pattern recognition, schema validation, and XSLT or AF transformations to do something very similar. If you've got a bunch of database code and fuzzy logic pattern recognition or whatever, and maybe those order entry clerks need to use their human intelligence on the corner cases, why bother putting the XML in the middle of things? Several reasons: - low impedence mismatch with hierarchical documents (unlike the relational model) - you can buy (or get free) rather than build most of the "boring" stuff. [aside - being "liberal" and accepting ill-formed XML negates this advantage, that's why being too liberal is a bad idea.] - The labels on the data make it relatively easy for the humans inolved -- either as programmers, pattern recognizers of last resort, or end users -- to deal with (especially when formatted with a stylesheet). Admittedly, this is essentially a matter of perspective, not technology. It might be hard to look at the code for a real system and determine whether it was "object centric" or "XML centric." Furthermore, the "XML is just a serialization format for my well- defined objects" approach has a lot of good use cases. There ain't no WAY I'm going to try to persuade Len Bullard not to use it for the kinds of highly-designed, tightly-coupled mission-critical systems one hopes that the military and public safety agencies deploy. But on the other hand, and I *think* this may be what Simon is getting at, I wish that more people appreciated that XML allows a middle path between totally mechanical processes that machines should perform and totally heuristic/artistic processes than only humans can perform. If you have nothing but "data" -- bureaucratically approved specifications, automatically generated data, machines as the end users -- the conventional approach works well. But if you have a lot of humans in the process -- changing specs, devising new business models, making sense out of weird data, or consuming the result -- the XML-centric design pattern can be very powerful. The response "make the humans play by the rules of sound engineering" won't work if you don't have the authority to make them behave, or your competitors have the ability to deal with them as they want to be treated. 
|
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
|
|||||||||
