Lambda the Ultimate

This isn't a terribly rigorous response, more a knee-jerk, but I do think this is an absolutely horrible idea. In the White Paper on the site, the authors quote Michael Kay's XSLT implementation of a Knights Tour solver as an example of the power of "XML Directed Solutions" - but as interesting as it is to see how a tree-transformation language like XSLT can be used to perform these kinds of computations, it beggars belief to think that anyone would seriously want to use it (or any other XML "vocabulary") as a general-purpose programming language. I'm completely at a loss here - why would anyone think that XML's syntax was appropriate for all the things they're trying to do here? And what on earth is a "pure XML perspective" anyway?

For backgrounders see Apache Cocoon and Steven P. Punte, a J2EE man in CS grad school. I have no opinion about X2EE, but think reasonably highly of Cocoon, which inspired it.

Cocoon I've looked at before - for the task at hand, which is rendering source documents/data in multiple document formats, it seems a pretty reasonable way to go. I'm one of those strange people who actually likes XSLT - it's just that it's the last language on earth I'd try to put any real application logic in.

I like, in general, the idea of declaratively configured process chains where you pipe processes together and tell them how to behave in a suitable configuration language. I just don't think a) that XML is that suitable a syntax for configuration languages (it's certainly overkill for name-value pairs), or b) that XML is at all suitable for writing the process logic itself.

Dominic's summary I do not think properly characterize the goal. XSLT is not the only possible process language; the white paper even gives SQL as an example. The idea is that all data between X2EE components is XML, and the processing components follow certain X2EE standards (also describable in XML) so they can be pipelined. Granted, X2EE does gush about XSLT overmuch, and I would not use it either, but I don't think X2EE enforces such a rule.

All data is viewed as XML documents, and all processes are viewed as XML transformations. The common denominator throughout this framework and consistent with many software efforts is the "XML Message Event" - an XML document being delivered from one software component to another as a event.

What does the quotation above lose if we remove every occurrence of the word xml?

All data is viewed as documents, and all processes are viewed as transformations. The common denominator throughout this framework and consistent with many software efforts is the "Message Event" - a document being delivered from one software component to another as an event.

We have a message-passing component framework, where components are arranged into pipelines; this is facilitated by having a common data type (document plus schema) for input and output. I don't at all disagree that this is worth doing (it seems a bit like sequencing actions in a monad to me), but I'm still mystified about why it's considered a good thing that all of the messages use XML's syntax. Isn't the syntax used for messaging the least complicated thing about such a system? How does using XML help you to deal with transactionality or concurrency, for instance?

Now that the first complaint is gone (XSLT isn't the sole processing language), on to the next one. XML has no advantage as a document format? That concept I would certainly dispute. You'd rather that messages/documents follow some weird, custom protocol? Should SOAP and XML-RPC melt under the same assault?

Knowing little about J2EE and X2EE (though a lot about XML), I do not wish to take up the cudgels defending X2EE. What I have done is invite Steve over here to do so. I'm sure he's open to constructive critiques and can speak more intelligently than me. His experience with J2EE must have fed the inspiration for X2EE. I'm curious to know exactly how.

Where I will concede a little ground to Dominic is that the unwashed masses do have an over-attraction to syntax issues, which somewhat feeds the XML hype. Still, XML has definite merit as an open standard. And I also think many of the XML practicioners recognize the hype for what it is (witness the Apache Cocoon intro linked above).

You'd rather that messages/documents follow some weird, custom protocol? Should SOAP and XML-RPC melt under the same assault?

I'd rather that messages/documents followed some suitable protocol, custom where necessary but obviously widely-adopted where possible. For some purposes XML is that protocol, or is at least a viable option (it inherits, to a restricted degree, the utility of SGML; it does have the advantage of being widely adopted). For others it really isn't. To give just one example: what's "weird" about CSV for SQL query results? Is it really harder to parse this:

ORDER_ID, PART_ID, QTY
23, 666, 4
13, 61, 3
...etc.

than this?

<orders>
   <order id="23">
      <part_id>666</part_id>
      <qty>4</qty>
   </order>
   <order id="13">
      <part_id>61</part_id>
      <qty>3</qty>
   </order>
   ...etc.
</orders>

Now I don't wish to be the obnoxious person who makes Steve Punte wish he hadn't gone to the trouble of coming and sharing a bit of his time with us, so I'll keep my mouth shut on SOAP and XML-RPC for the moment - the truth of the matter is that I have only opinions to offer here, and not especially well-considered (much less researched) ones at that, so it will be much more interesting to hear a thinking practitioner explain what he's about.

I do like this quotation from the Apache Cocoon intro, though:

Just like you shouldn't care if somebody offers you software that is "ASCII compliant" or "ASCII based", you shouldn't care about "XML compliant" or "XML based": it doesn't mean anything.

(And I do quite admire Cocoon, incidentally).

The problem is take the next step. What if your items have structure? Once you make this leap you get into a more complex description and notation. Might as well just start there. Plus, for debug, logging, and sniffing it is useful to have a self describing format. Plus, everyone can use the same toolset without requiring a custom parser for each message type. Plus, adding versioning is much trickier with your simple format. Plus, internally, we often serialize to binary format :-)

The Kight's Tour example is quite good, actually, since it demonstrates the insanity of trying to write a program in XML. It's not even easily readable, much less easy to write. There's a huge amount of--useless to the programmer--syntactic sugar in it, too,

Dominic: Is it really harder to parse this...

Given the vast library of XML parsers out there, the XML is easier to parse. The resulting parser is also easier to change and more future-proofed as well.

That isolated example misses the point anyway. To see it, multiply the number of components and data repositories. One can be SQL. Another can be HTML. Another can be spreadsheets. Another can be proprietary binary format X. This is where data normalization shines. If one wants future-proofed, plug-and-play capabilities for N processing components, but lacks data normalization, then one must write N*(N-1) translation interfaces to get them all speaking each other's language. So data normalization is good, and XML is an obvious candidate for that job. Inserting one more component means writing 1 translation interface (if it's not already XML-based) instead of N.

Oh well. I've tried to email Steve but got bouncebacks. Maybe someone else can contact him. I've taken enough bruises for one day.

I think the best response was stated thusly...

Isn't the syntax used for messaging the least complicated thing about such a system?

The interesting bits of this system would be in the data model, and not the syntax of how the data model is exchanged.

I am not sure what is interesting about this framework, per se, though. CORBA 3.0 is more interesting, more mature, and has more features (synchronous and asynchronous). (Not that I'm trying to sell CORBA 3.0 either, but at least it is much further along. Adding XML to CORBA 3.0 might be the place to begin evaluating the merits of this kind of system, which appears to be the CORBA 3.0 Component Model with XML as the interchange format.)

Another system (really, a specification-in-progress) that seems a better starting place would be the Java Business Integration effort. Making this effort multi-lingual would be more interesting than simply reinventing the CORBA 3.0 Componente Model using XML as the interchange format.

Todd asked:

What if your items have structure?

It depends on the structure. If you look at Topic Maps, for instance, you see that a lot of the real structure of the data is expressed through id and xlink:href attributes - the equivalent of simlinks in a hierarchical file system. In XML Schema, type or structure definitions that are used in more than one place are often given global scope and cross-referenced instead of being nested hierarchically. XML is a reasonably good fit for a particular kind of data structure: nested scopes, or the node tree represented by the DOM. For data structures such as Topic Maps, XML's syntax has very few advantages. In cases where the data structure really is complex, you'd be better off with a syntax that enabled you to express relations cleanly and economically. XML ain't that syntax.

On to Mark's comments, and I'm sorry if he's feeling bruised (my fault for surfing over to LtU directly from Slashdot - one forgets how to be civilised after a few seasons in the abyss...):

I'm sure there are library parsers for most languages for reading CSV; if there isn't one for your language, it's hardly a big deal to knock one up. You only need to do it once (per language) - or use a regexp. While I agree that it's a good thing that there are widely-distributed and standardised parsers for XML, I don't think this is the strongest part of its "value proposition" when the comparison is with relatively straightforward - and also quite standard - alternative formats.

The argument in favour of data normalisation I think has more about it. One interesting dimension of this is that you can write a parser for a non-XML format - say CSV - that fires SAX events. If the data consumer also builds its internal data structure by handling SAX events, then it's possible to plug the non-XML SAX-event-emitting parser directly into the SAX-event-consuming process, without at any stage generating an encoded XML stream to pass between them. In other words, given a common API for marshalling and unmarshalling data values, and one marshaller/unmarshaller per document format, you don't necessarily need a common syntax - or a common encoding - at all. (I believe Cocoon actually hooks SAX event-producers straight up to SAX event-consumers internally, rather than passing around fully-encoded XML streams).

In this scenario, XML is just what SAX events look like on the wire - it enables the marshalling of data to take place at the data producer's end, and the unmarshalling to take place at the data consumer's end, so that responsibility for marshalling and unmarshalling data (also for knowing how to marshall and unmarshall data) can be localised appropriately in a distributed environment. So XML is a data transfer format for a node-tree-producing-and-consuming data marshalling API - neither a data type, nor a data model, and certainly not a "perspective"...

The problem with corba, without going to an any type, is any change requires a recompile of all impacted elements and you can't handle all messages at a meta level. With XML you have an important form of versioning where elements can be added transparently without breaking old apps at all. You can also have a layer that handles all requests and dispatches them. This is useful for logging, validation, security checks, and integrating better with application architectures.

Also, the model of handling requests in ORB threads is a bad appliction architecture. Not sure if this addressed in 3.0 though.

I tend to work with complicated request formats at the service level. In this world there is lots of structure and lots of evolution from release to release. For simple things who really cares. As the world gets more complex it does matter and XML helps.

The DOM is a good idea in that complex messages are helped by having a generic access structure. Often on a project this is built by hand or generated from message definitions. Unfortunately, i've found the dom interfaces very low level and painful to use.

There are a lot of different points you can choose along the functionality/tradeoff curve. With XML, for example, we can validate a message format before giving it to applications. Very important if you want to avoid denial of service type attacks based on bad data. With CSV you would need to recreate this infrastructure. We also do audit and security logging and trace logging because we can look for certain parts in an XML message. You can't do this with CSV. We can use of the box sniffers that underestand XML.

The capabilities of a self describing structure have proved very useful. We can easily merge in new data into a message. Consider an application stack where data is transformed at each level in the stack. We can do this automagically at a meta level without regard to structure.

XML works well enough. Messaging formats are endless debate. It might be a good time to declare victory and move on to more at interesting issues.

Patrick: The interesting bits of this system would be in the data model, and not the syntax of how the data model is exchanged

There's more to XML than syntax. (I was just asked a specific question about parsing, so I answered it.) Anyhow, X2EE seeks to provide a framework in which the programmer can focus on the interesting bits, right? So it's all about how the data is exchanged, not what is done with it. In the same vein, SOAP and XML-RPC are not about the functions being invoked, but the data transport mechanism. The remark here is equivalent to the statement that "The interesting bits of the highway system are the destinations." In a sense that is true, but...someone has to design the highway system and the car. That's all X2EE amounts to, a highway system.

For X2EE the distinction between "message" and "data" is illusory. The "messages" are, in fact, the data, normalized to XML format. I would not view X2EE as attempting to provide a "messaging framework" in the usual connotations of that term.

What I do not understand is the appreciation expressed for Apache Cocoon coupled to disdain for X2EE. Why shouldn't business data benefit from the Cocoon approach?

Todd: It might be a good time to declare victory and move on to more at interesting issues.

And that without hearing from X2EE's originator. LtU is nothing if not efficient. Someone please mail X2EE the laurel wreath in a sturdy box, courtesy LtU. :-)

Far be it for me to defend CORBA's design, but here I am. The ORB architecture itself has become essentially a framework for a simple TP monitor. The component model is a framework for a more elaborate TP monitor (essentially a multi-lingual EJB with some design improvements). And the whole system includes asynchronous as well as synchronous communication.

Not perfect, but fairly mature. The whole web services movement seems to be 1/2 ignorant of where CORBA matured and 1/2 in silent insurrection of where CORBA matured. (i.e. DCOM didn't cut it, so XML and Web Services became the "it" girl of the 2000's without being overly obvious.)

Tim Bray disagrees with you:

The notion that there is an "XML data model" is silly and unsupported by real-world evidence. The definition of XML is syntactic: the "Infoset" is an afterthought and in any case is far indeed from being a data model specification that a programmer could work with. Empirical evidence: I can point to a handful of different popular XML-in-Java APIs each of which has its own data model and each of which works. So why would you think that there's a data model there to build a language around?

I don't agree 100% with Bray (particularly the `real-world evidence' bit, which is irrelevant), but IMO strictly speaking (untyped) XML has an initial sort of semantics, if you know what that means; it's not far from saying it has no semantics. In particular, in general, an`XML application' by definition must have access to information like comments, processing instructions and whitespace even in element-only content. XML Infoset applications are a subclass (variety) of XML applications which don't have access to these things.

This is analagous in algebra to homomorphisms of a monoid versus homomorphisms of a commutative monoid; the latter have no access to the order of elements or, put another way, must not distinguish terms which differ only in the order of elements.

I mostly agree with that Frank. Please recall the context of my remark - it wasn't intended to impute a data model in abstract XML, Bray's boxing bag. (Though, come to that, he sidesteps end-user schema validation to yak about the Infoset, picking his battle carefully.) What I meant was that comparing XML to any one-off custom format - on pure syntax, in isolation, with no reference to the outside world, as per Dominic - is an apples-to-oranges comparison. Broader concerns are involved: the widespread usage of XML, the open source tools, validation, etc. That's the "more" in XML, if you please. Finally, I cannot imagine that companies like Microsoft and Oracle, full of Ph.D. computer scientists, are so dumb as to fall for XML without good reasons beyond syntax.

There are premises here that only dumb people get swept away by hype and that a technology needs to be deep to garner attention.

Technical people love new problems to work on, so a new technology is always an easy sell, provided it will pay the bills. XML produced a whole new source of funding in both industry and academia.

So the combination of new problems and lots of money is likely to attract smart people more than dummies. ;-)

Is XML really worth all that? Is it deep? I think its technical merits boil down to a simple idea: let's have a standard format for structured text files. But what is really amazing is that it is a standard that everyone actually uses (in fact over-uses).

That alone puts it ahead of all the other creaky technologies that sounded great, and everyone paid lip service too, but never really used.

Does a Ph.D at a big multi-national really need any more reasons to go along with XML than those?

I said companies, not people. Companies are collections of individuals sharing a profit motive, competition, and market research knowledge, on top of technical engineering sense. That is not to say anything about "dumb" people, whomever they may be.

XML shares with HTML the heritage of SGML, which I suppose might qualify it as "deep," depending what you mean. Certainly HTML changed our world, so I give XML a fighting chance.