RE: terra incognita
> -----Original Message----- > From: Simon St.Laurent [mailto:simonstl@s...] > Sent: Sunday, December 16, 2001 8:59 PM > To: xml-dev@l... > Subject: terra incognita > > Maybe I've been working in the XML trenches too long, but it > seems like maybe it's time to say "XML is different from the rest of what you've > been working on, and we should take that seriously" rather than > pretending that XML is simply glue for other technologies. Interesting ... I came back from XML 2001 thinking very similar thoughts. There was some convergence of stimuli there that clarified in my mind a dichotomy between the folks who think of XML as a serialization format for their strongly typed objects and the folks who think of XML as the native representation for their streams of documents and messages. I heard two presentations that discussed this dichotomy in almost exactly the terms that Simon uses: XML - A Disruptive Influence on Programming Languages and Methodologies Presented by: Denis S. Kirkham, Sun Microsystems This presentation will explore how to-days programming languages and methodologies assist or inhibit developers in building the next generation of XML centric systems. and XPipe - An XML Processing Methodology Presented by: Sean McGrath, Propylon XPipe is a methodology that promotes the assembly line principle, long established in other areas of manufacturing, as the key to the industrialization of XML processing. This session will discuss the Xpipe methodology. [BTW, I didn't find a CD with the conference papers/presentations amidst my trinkets and trash collected at the conference, but kept hearing references to such a thing. If there are formal papers for either of these on the CD I'd much appreciate copies, or pointers to them online.] I've been puzzling over this all weekend, and I can't quite sort things out along coherent dimensions. Nevertheless, there seem to be at least two distinct clusters of XML technologies/philosophies: 1) Those that take strongly typed schemas, whether they be XSD schemas, classes in an object-oriented programming languages, or relational database schema as their focus. They tend to use strongly typed programming languages, validating parsers, and care about things such as whether the result of their queries or XSLT transforms are valid with respect to some schema. Most, not all, probably think of SOAP as an RPC protocol allowing well-defined objects in one domain to communicate across platforms with well-defined objects in some other domain. For them, storing their objects in an OODBMS or in an RDBMS is the obvious and logical thing to do. I'm pretty sure that this is the dominant conception of XML at Microsoft, Oracle, and IBM, at least as far as I can deconstruct their various public pronouncements. 2) Those that take well-formed but informally-described XML documents or messages as their focus. They tend to use untyped scripting languages, non-validating parsers (or use some combination of declarative and procedural validation), and use queries and XSLT as simply convenient ways of adding or extracting information from chunks of XML. Many are skeptical of web services or are exploring non-RPC conceptions of web services such as that supported by RogueWave's Ruple technology. http://www.roguewave.com/developer/tac/ruple/ (RogueWave was at the conference, but didn't have a formal presentation AFAIK). For them, storing/exchanging their XML natively (in an XML "space" like Ruple, a native XML database, or even the filesystem) is the obvious and logical thing to do. I'm not sure what to call this perspective (and no big company seems to advocate it), how about the "native XML dataflow/transformation" perspective??? (A better label is humbly solicited from anyone who sees the world this way). I dunno, this may be simply my personal clustering into things that I find overwhelming and confusing and things that I find simple and natural. But it's not really about one perspective being "better" than the other; I will very happily admit that there are PLENTY of good use cases for the "XML for smart serialization of RDBMS or objects" perspective. Nevertheless, a clear alternative seems to be taking shape, and I think the distinction, and the use cases in which one or the other is more appropriate, deserve exploration.
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