[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> Sent: Sunday, December 16, 2001 8:59 PM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] 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.
|
