Introducing o:XML
by Martin Klang
|
Pages: 1, 2
X is for eXtensible
As expected, o:XML provides the same capabilities as most other modern languages. Being XML, it also allows for processing and extensions, which doesn't come naturally to conventional programming languages. What this means in practice is firstly that we can harness the power of tools and technology developed for XML. Secondly, our code integrates seamlessly with practically every other XML vocabulary.
We've just seen how o:XML programs can be in-lined in RSS, or used to generate SVG output. We will now take a brief look at how the source code itself can be extended.
The following is an example taken from the o:Lib implementation of an internet message. It includes two separate extensions: Documentation and Unit Tests. The automated build produces cross-referenced type documentation, unit tests, and test results. This is achieved with standard XML processing tools such as XSLT and an o:XML interpreter.
Example 6: Extensions in net:Message
<o:type name="net:Message">
<doc:p>Represents an RFC822 Internet Message</doc:p> 1
<o:function name="header">
<o:param name="name"/>
<doc:p>Get a message header</doc:p> 2
<o:do>
<o:return select="$headers.get($name)"/>
</o:do>
<ut:test> 3
<ut:input ref="msg1"/> 4
<ut:definition> 5
<o:set msg="net:Message($input.string())"/>
<o:return select="$msg.header('Host')"/>
</ut:definition>
<ut:result>localhost:8090</ut:result> 6
</ut:test>
</o:function>
<ut:dataset name="msg1"> 7
Content-Type: text/plain
Content-Length: 8
TestData
</ut:dataset>
</o:type>
- Type documentation.
- Function documentation.
- Unit test declaration.
- Test input declaration.
- Test definition.
- Expected test result.
- Test data definition.
There are no inherent limitations to the type or nature of extensions that may be incorporated into o:XML source code, as long as the data can be expressed in XML. Currently available extensions vary from documentation and embedded tests to declarations that alter the behavior of an application, such as Design By Contract assertions and Aspect Oriented Software Development definitions.
The possibilities are almost endless: An integrated development lifecycle starting with requirements, through definition and UML modeling, to development, test plans, and deployment, could be centered around a common XML information repository.
Why o:XML?
And so we return to the question: Why o:XML? My preferred answer would be: Using the same format for code as we use for data allows us to think slightly differently about the code. The application is not only a runtime executable, magically incantated by the source code -- it is structured data, information, a document!
With XML, the source code is made transparent, it can be processed in the same way, with the same tools that we use for other structured information. Writing o:XML programs that generate or instrument other programs is remarkably easy. The XML code format allows for orthogonal extensions, integrates with development methodologies, and is a natural test-bed for abstract languages, meta-programming, and reflective programming.
o:XML is a practical language, designed to solve practical problems. For many types of applications it already provides faster, easier, better solutions than any other technology. If you are writing code that processes or produces XML, chances are you will benefit from using o:XML.
Related Work
There is a growing interest in defining an abstract XML programming language, and several independent projects have been started. One of the more evolved ones is Marko Topolnik's Jezix, which currently has a focus on Java but intends to be independent of the source language. The main purpose of Jezix is to provide a source-code representation for automated manipulations and orthogonal extensions. Another interesting project is JavaML, which aims to provide an XML representation of Java.
Other languages that have deep XML integration and treat XML as first-class constructs are XDuce and Water. XDuce is a functional language, while Water is object-oriented with a focus on web services. However, they both use a proprietary, non-XML syntax.
The field of web application programming was possibly the first to embrace the use of XML to encode business logic. JSTL provides a library for programming constructs that makes it possible to build logic blocks in XML. Jelly is an Apache project that builds on JSTL to enable easy integration of XML pipelines with Java code. TagBox, in turn, is a project that has grown to be a complete, extensible 4GL. It now supports procedure and module definitions in XML. Still, none of these technologies are really programming languages in their own right, and don't offer much in terms of abstraction mechanisms.
Project Status
The key component of o:XML is the Java-based compiler and interpreter, ObjectBox, which recently went into production release with version 1.0. ObjectBox allows o:XML programs to run standalone, from an Ant build file, or within a servlet engine such as Tomcat. It also allows for integration with existing Java applications using either BSF or its own API. ObjectBox currently offers a full, stable implementation of o:XML.
The core language is supported by extensions and library code. The o:XML standard library is o:Lib, which in its first release includes file, stream, network, and XSLT functionality.
In addition to library code there are also several language extensions available. Java extensions allow Java classes to be used seamlessly in o:XML programs. The popular database extensions handle database connection pooling and transactions, while providing a uniquely simple, powerful, RDBMS-to-XML mapping mechanism.
The compiler/interpreter also has experimental support for reflection. The reflection extensions expose runtime information, such as types and functions, in XML format. This opens the information up for easy manipulation using XPath. For example, groups of type functions can be selected with simple XPath expressions based on their names, parameter types, or attributes of the types they belong to. The extension supports higher-order functions, partial function completion, and the usual reflection types.
Another attractive quality of XML programming languages is that they can be machine-translated using readily available technology. There is an experimental XSL transformation of o:XML programs into plain Java that has been developed as part of the o:XML project. It is still only partially complete but working. A more complete, public release will be available in the near future.
Looking to the Future
Since the first public release in early 2002, o:XML has certainly come a long way. And there's an awful lot of activity and related projects with deliverables currently in the pipeline. I think we can expect the field of XML programming to grow at an ever-accelerating rate in the next few years, taking both markup languages and programming in general to new levels.
Work has already started on the next-generation o:XML compiler. It will be centered on a portable, native-language, transformation engine. The goal is to produce efficient code for a number of targets, including Java Bytecode and C, using o:XML tools throughout.
There is also scope for producing a minimal-footprint engine for embedded and portable devices, such as PDAs and mobile phones. With the right tools, o:XML programs can be transformed into highly optimized code targeted at restricted or specialized platforms.
A great deal of work has already taken place on lifecycle and methodology integration. o:XML lends itself to processing and code generation like no other language, and using XML tools means that every step in the process is transparent. There's more information about workflow integration on the o:XML web site.
In the department of orthogonal source-code extensions, there lot's of work underway on developing standards and tools. Unit test and documentation extensions are currently put to use across several projects. The specification and implementation of Design By Contract extensions were part of a paper presented at the Extreme Markup Conference 2003. The paper, XML and the Art of Code Maintenance, also included blueprints for Aspect Oriented Software Development in o:XML, which has since been further developed. Expect a public release soon!
Open Source o:XML Projects
| ObjectBox | o:XML compiler and interpreter in Java |
| hatatap | HTTP test script language and tools |
| vendue | Online auctioning software written in o:XML with db extensions |
| o:Lib | o:XML core libraries |
Resources
|
Share your experience in our forums.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Newest First |
- Jezix correction
2004-08-25 02:48:51 Martin Klang [Reply]
I'm afraid that I somewhat misrepresented the goals of Jezix. This is due to my own misunderstanding.
In reality, Jezix is: "a research project on the requirements and design principles for XML grammars of the source code of programming languages."
- Comparison of SuperX++ and o:XML Needed
2004-07-25 07:11:18 Roy Roebuck [Reply]
I suggest a third party provide a comparison of the o:XML and SuperX++ object-oriented programming languages.
- Comparison of SuperX++ and o:XML Needed
2004-07-26 16:56:28 Martin Klang [Reply]
I think that is an excellent idea, and I'm sure Kimanzi Mati (of SuperX++) agrees. Both projects have great potential. Anyone interested in writing such an article should contact XML.com, myself or Kimanzi.
- Comparison of SuperX++ and o:XML Needed
- Poor reimplementation of LISP
2004-07-23 06:41:17 Foob [Reply]
For those too obsessed with XML-trendiness to realise - this is extremely similar in a lot of ways to LISP, which is a lot more powerful and elegant and uses S-expressions rather than XML syntax. Suggest anyone who likes the sound of this tries out LISP before investing the time learning to work with this monstrosity.
Common ideas - representing code and data using the same type of syntax, extensibility of the language, mark-up style syntax (LISP's is a lot less convoluted than XML as it doesn't need to distinguish between tag names and attributes).
Guys, why not just write a front-end to LISP that converts XML into S-expressions?
- Poor reimplementation of LISP
2004-07-30 03:14:33 PeterVerhas [Reply]
This is exactly the comment that came up in my mind when I was reading the article. In 1991 we implemented LIST data structures and data store for the language in a project. This time a language is born on the top of the data.
- Poor reimplementation of LISP
2004-07-23 07:07:46 Martin Klang [Reply]
> why not just write a front-end to LISP that converts XML into S-expressions?
You can have it in Perl:
http://www.lisp-p.org/xml/
or in XSLT:
http://www.eros-os.org/pipermail/e-lang/2001-September/005694.html
Nice to see that so many Lisp enthusiasts are reading XML.com!
- Poor reimplementation of LISP
- o:XML and extensible programming systems
2004-07-23 06:01:21 GregWilson [Reply]
Readers of this article might also be interested in a piece I originally did for Doctor Dobb's Journal (www.ddj.com), which I have revised and put on line at http://www.third-bit.com/~gvwilson/xmlprog.html. In brief, I believe that the shift to representing code in XML is almost inevitable at this point, but (a) it isn't going to take off until we can give programmers WYSIWYG editors capable of handling rich content (like in-line SVG and MathML), and (b) the real benefit will be that this shift will make high-level program manipulation feasible.
- Greg Wilson
- o:XML and extensible programming systems
2004-07-26 17:17:08 Martin Klang [Reply]
It's a very good article and the argument goes along similar lines of processability and extensibility of XML languages.
I personally think that 'the future is here' - using a language such as o:XML gives immediate benefits that cannot be neglected. Simple things like extending a type definition with test cases is _really_ easy. Producing high quality documentation is _really_ easy. The source code has real value as structured, accessible and unambiguous data. And when using a schema-aware editor (such as Emacs), o:XML is not very difficult to code in either.
- o:XML and extensible programming systems
- Superx++
2004-07-23 04:23:10 Martin Klang [Reply]
Since writing the article I have discovered there is at least one more XML-based OO language available, and probably more that I don't know about - it is called SuperX++ and can be found here: http://xplusplus.sourceforge.net
Another project that may be of interest is MetaL:
http://www.meta-language.net/
Apologies for the omissions!
- o:XML == Lisp?
2004-07-23 04:19:08 Baczek [Reply]
This is the ulitmate proof that XML was done 40 years ago (and IMHO better, as mathematics is always better than marketing ;p)
- o:XML == Lisp?
2004-07-30 17:57:04 Martin Klang [Reply]
Sorry for the belated reply, I was hoping someone else might pick up the gauntlet...
Lisp is indeed a beautiful language, not only conceptually but also in its minimalist syntax.
Still I wouldn't choose to use it to build XML applications. o:XML on the other hand is in this respect truly useful.
XML is also, IMHO, a superior data format to Lisp - with namespaces, character encodings, end-tags (!) and a vast array of processing tools. Source code being structured, hierarchical data provides a perfect match for XML. Hence o:XML.
As for the claim that o:XML equals Lisp - firstly I am honoured. Secondly: I believe equivalence implies the existence of an isomorphic mapping. I've already provided links for converting XML to Lisp. Does anyone know how to convert it back - to the exact same XML?
- o:XML == Lisp?
