After my recent post on X++, I got a reply from Kimanzi Mati (the author of X++) with some interesting comments.  I have posted this reply in its entirety here, and I wanted to address a couple of the items here.

Right now, all the XML data is public to the non-XML process that uses the XML data.  This is a problem, I think, which needs to be addressed.  This is where x++ objects come in as they will encapsulate the data within XML itself.  The other thing is of course that the objects can be sent via HTTP to remote machines and used there; all the while preserving the access security of the data.

Well, I’m not sure it is a “problem” – it depends what you’re using the data for.  For example, in a document-based SOAP message, the payload is thought of as a XML document in and of itself, rather than as a representation of other data (such as in RPC endoded messages).  You’re also not necessarily preserving access security of the data, because as you say, all of the data is being transmitted to the remote process.  At best, the embedded x++ code is a recommendation of access; not a requirement.

Some would say that this is mish-mashing code and data together in a bad way.  I would say no: XML is the format.  All objects in all object oriented systems encapsulate data within them.  In addition, of course, they have methods to implement behaviour.

In terms of traditional OO thinking, you’re right – objects encapsulate data and behavior.  However, in modern transactional and message-driven systems, the data and behavior are becoming somewhat separated by necessity.

In a nutshell, my thought is this: why can there not be a full programming language based on XML?  There is no reason, which is of course one of the reasons why I set out to invent x++.

I totally agree, and never meant to imply that there could not be a XML-based programming language.  I’m just trying to explore the possible uses for such a language, and how they might fit into modern transactional and service-based architectures.

I do find the idea of shipping an object, encapsulating both state and behavior, described in XML, via SOAP, to be interesting…