RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to Love daBomb)

["Simon St.Laurent" <simonstl@simonstl.com>]

On 21 Aug 2001 15:28:28 -0700, Michael Brennan wrote:
> Except that somewhere there is a program driving that conversation.

Sure, but binding those programs tightly together is usually a bad idea,
especially when more than one participant is involved in the
conversation.

> Nonetheless, I think you make valid points, and for this same reason I think
> that of all of the things the W3C has given us, the DOM is probably the one
> with the least value.

I'm not completely sure what you mean here, but I'm not inclined to
disagree, either.

> In our own software we leverage a custom XSLT-like technology that lets us
> define in a declarative fashion the data structures we wish to extract from
> an XML message, and define mappings between these structures and the XML
> format for a particular message. We can also hook in arbitrary code at
> particular points to allow us to do any additional processing not
> accommodated with the declarative syntax. This affords us a rather malleable
> layer that sits between our own engine and the external interface we expose
> to customers and partners. However, the technologies are such today that you
> often drop into code at some point, and then you are typically stuck with
> the DOM or SAX. We are exploring ways to strike those from the APIs and let
> developers work at higher levels of abstraction when they do need to drop
> into code while still supporting that flexible modeling of conversations. 

Abstraction is a useful concept, when under the control of the
developers.  SOAP strikes me as horrible means of managing such
abstraction.  I'd really rather see developers deal with the need for
code than bind themselves into shared API straitjackets.

And yes, I know SOAP lets you wrap arbitrary documents, but if I wanted
arbitrary documents, why waste cycles in SOAP?

> Developers still need to write business logic, and they need to get the
> information from the XML document into data structures better suited to
> supporting that business logic. All of the APIs in the XML world are
> unsuited for this. They force the developer to mold their logic to fit an
> API that is only suited for modeling a document structure, rather than
> letting the developer mold their data structures and APIs to align with
> business concepts and processes.

That sounds reasonable, but it hardly sounds like a ringing endorsement
for API models in general or SOAP in particular...

Needing better APIs for direct XML processing doesn't sound like cause
to run to a higher level of API abstraction that leaves you largely
stuck in the land of APIs.  It seems that we could certainly do
something more creative than that.