ProDML - Process Description Markup Language

The central idea behind this came to me during an XSLT course at my place of work.

Introduction

XSLT is used to transform XML documents into other XML documents or into other types of output (e.g. text files, HTML files).

Imagine if we defined a language with which we could describe processes which we need to carry out. This is called ProDML (Process Description Markup Language). A simple example would be:

<process>
<print>Hello World!</print>
</process>

If I ran this through my XSLT processor and used ProDML2Python.xsl as a stylesheet, the output would be:

print "Hello World!"

If I have the relevant stylesheets, I could express my process in any programing language I chose.

Going from Python to ProDML

Let's say that some kind person implemented a Python2ProDML module. This would translate Python code into ProDML. I could, if I chose to, use ProDML as the format my scripts are saved in. When I open them for editing, they would automatically by transformed into the language (and the version of that language) I prefer to work in.

If I wrote some scripts in an earlier version of Python this would not matter as they are stored in (or can be transformed into) ProDML, and so can be translated into whatever version of Python I want to use. The same goes for using scripts created in a later version of Python than the one I have installed. So long as I can go via ProDML, I can run and/or edit the script.

Depending on the level of detail captured in ProDML, I could either get the code back as I entered it (with a few minor differences, such as the normalisation of non-syntactically relevant white space), or perhaps optimised in some way, i.e. the output code would do the same thing as the code I wrote, but do it faster or perhaps be expressed more succinctly. (This is analogous to an optimising compiler - here the source code is the result of the "compilation" of the proDML).

Collaborative working

Let's say I'm working on a project with my colleague Denis. Denis is a Perl guru. I prefer Python. If we use languages with ProDML support, we can write in whatever language we choose, even if we both need to work on the same scripts. Potentially, we could work collaboratively with many other people, all using different languages. If we use ProDML as a storage or intermediate format, which language I or anyone else uses becomes irrelevant.

If there is a preferred language which the final executable needs to be compiled from we can transform our project into this language, and compile.

Perhaps we could write a compiler for ProDML. Then any language could be compiled using the same compiler. This one compiler would repay optimisation many times over, as users of all languages would benefit form improving its performance. (It might also be possible to debug or run ProDML natively, without needing to translate it into any particular language).

Archiving

ProDML could be used as an archiving language. As it is in XML, it is effectively in plain text, and so is independent of operating system or any particular vendor. So long as the "atomic" procedures described in ProDML are understandable (e.g. a person trying to understand the process knows what print actually means), a translator can be written to give output in a form that can be used by a computer (or person) to carry out the process.

Requirements

Would require:

• A well designed ProDML vocabulary
• The ability to translate computer languages into ProDML
• The ability to translate ProDML into computer languages

Problems

Handling incomplete or buggy code.
If code in a particular language doesn't run, we can't reliably parse it programmatically to determine what the code is intended to do. In this case we can't be certain that our ProDML either can be created, or, if it is created, if it actually matches the intentions of the person who wrote the code. (The latter problem is not unique to ProDML, but affects functioning but bad code in any language).

Potentially massive ProDML files
Recursive functions and control statements could require a level of abstraction if overly large ProDML files are to be avoided. This would complicate the creation and transformation of ProDML, and may make the required translator/stylesheets too complicated. The provision of a set of simple tools in the XSLT processor may be a simple answer to this. Certain tools already exist in the XSLT specification. They may already provide all that is required.

(On reflection, I think that the above may not be such a problem, as all we have to do is describe the meaning of the iteration, not express all of its iterations in markup. Silly me.)

Turing Type Limitations
It may not actually be possible to do the computations necessary for the process to work. The halting problem might be relevant here..