Hiding XML

Data centric XML examples would be RDF or RosettaNet. Here, of course, the purpose of the XML syntax and semantics are to store data that is acted upon by other systems and convey some meaning or context about that data.

Executable centric examples would include XSL, BPEL, BPML, DPML, and ant, to name but a few. These examples act on data living in XML or on other systems.

Fortunately it is rare that I ever create a data centric XML document unless for testing or prototyping. Tools like Jena for RDF, and other base XML libraries, do much of the work.

But the manual writing and editing of executable XML has become quite burdensome. Yes there are tools that let you visually build some of these kinds of XML documents. But that is far from sufficient, let alone convenient, when actually building a real application based on these languages.

For example, some popular BPEL tools let you drag and drop visual elements and build connections between them. By doing this, you are creating the BPEL XML document needed by the BPEL engine. But repetitive drag/drop/right-click/edit/apply is it's own form of water torture. Generally the ability to switch between each mode, visual and XML, is handy. But maybe there should be a third representation.

The RDF folk have it right. RDF is a model. And this model can be represented in many formats like RDF/XML and N3.

XML is good for human inspection, and great for machine interpretation and communication. Yet lousy for human editing.

In a world where I don't write Ruby or Python applications of any meaningful size or complexity because IDEA doesn't support those languages as naturally as it does Java, I find myself torn when faced with the decision to use an XML scripting language or just write it in java and live with the consequences.

I would love to see more languages, but they need to be in a form usable by humans, atleast at the presentation level. If a visual notation can be attached to many of these executable XML languages, then a syntactically friendly version can be created in the same fashion as RDF.

And if there was a standard way to map XML elements/attributes and their semantics into a simple piece of text or template or AST, it probably would be little effort for an editor to load that mapping and provide all the productivity features usually afforded someone editing a popular language.

This being an oversimpilification, do note that may of the executable languages do have very common constructs like if/then, loops, lists/maps/sequences, scope/namespace, comments, variables and assignment. But every XML language has it's own syntax or means of representing the construct.

So imagine having the ability to write code in some form of Java or C# script, a dialect you have some familiarity with, where the editor (or tool) can translate that script to the target machine readable format. Since there isn't any massive optimization of the 'machine code', it can be re-read by the editor and translated back into the more usable scripting syntax or to a visual model for editing by other stakeholders.