1/29/2002 1:21:09 AM, "Simon St.Laurent" <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.






-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>