[
Lists Home |
Date Index |
Thread Index
]
1/29/2002 1:21:09 AM, "Simon St.Laurent" <simonstl@simonstl.com>
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.
|
