HLL XPL, what is it and why do you want it?
What is it?
The core component of XPL (eXtensible Process Language) is a parser for files structured as XML. Its non-standard feature is that it allows XML's restricted special characters ( <, &, >, ", ' ) in text without any special handling.
Is it hard to learn and use?
It's easy to learn XPL and how to use it; almost nothing to it if you're already familiar with XML processing. XPL is very much like XML, except that it allows XML's special characters in text elements. The XPL process looks like StAX, Java's most recent, fast and light-weight XML processing model. If you're relatively new to XML, it's not an extra strain on your learning time. In fact, StAX-PL is simpler than XML StAX. So starting with StAX-PL gives a good simple introduction to the processing model.
Why is it needed?
XML is an extremely popular standard data file format defined by The World Wide Web Consortium (W3C). It has reading, writing, and processing support built into popular programming languages. By definition, standard processing components are not allowed to process special characters that are commonly used in the expression of logic (program source code) without special treatment. There are some uses of XML in the HLL Project that would be impractical without XPL.
Special characters can be included in standard XML files if they are represented differently ( for example, < written as < or < ), or presented as CDATA.
Then why use XPL?
Because you want to use XML, but you don't want the hassle of changing all the details of your code or a big pile of CDATA wrappings that make your files harder to write, read, and maintain. You can even copy-paste code fragments directly into an XPL file using any editor or automatically create XPL files that are easy to read and maintain with any tool.
Is that important?
If you want to store source code in XML, it's a major plus if it can be expressed exactly the way source code is normally expressed; the more code/data, the more important it is. Experience has shown that the difference is not trivial if you're doing much work with code expressed as data.
But I want to use XML!
And you can. In limited circumstances, you can use XPL as a direct replacment for XML. But when you need full-featured XML processing, the XPL parser is intended for use as a preprocessor, transforming XPL into valid, standard XML. The source code included with XPL includes XML StAX, SAX, and DOM processing, either by creating intermediate XML files or piping XPL parser output directly into an XML process. The SAX source code included shows you how to use Java concurrency so there is no performance cost for pre-processing.
XPL was not designed to replace XML and can only be used as a direct replacement for relatively simple processing, as when namespaces (which the v1 XPL parser treats only as attributes) are irrelevant, you aren't doing real-time validation, and you aren't using markup technolgies like XSLT and XPATH. When more complete XML processing is required, use the XPL parser as a preprocessor to XML. When the need for special character processing is very light, engineering judgment can easily fall toward adapting your code to standard XML by hand. Unless you already have the XPL parser of course. If you have it, it's generally easier to use it.
Is XPL perfect?
It's pretty good, IMO. It's designed to be really fast. It allows you to store source code in XML structures, which the HLL Project has found has significant advantages in creating and maintaining "code as data" files. It can be said that HLL loves XML and avoids home-grown logic storage alternatives that are more complex and have steeper learning curves. Why completely reinvent the wheel? XPL was created to facilitate continued use of XML outside the purpose for which XML was designed.
But it's not quite perfect (yet). There are a very small number of additional rules, beyond those of XML (minus special character problems) that you must follow when using XPL. If you're used to writing "if (var1<var2)" instead of "if (var1 < var2)" with spaces, then you will need to adapt by including a space after the < symbol. However, "if (var1<4)" is perfectly acceptable.
Will XPL ever become a standard and integrated with languages like XML?
I can certainly dream that it will and if sponsored I'd love to drive the effort. If XPL becomes so popular that standardization becomes a serious issue, I'll open source the code and the parser will be free, even though the project needs the funding. XPL and XML can work very well together and we can all just get on with the task of building great software that expresses code as data. But I have a somewhat different perspective when thinking farther ahead.
Within 50 years I expect XML will no longer exist. Why would I predict that, especially about something I've already said is great? There is a lot of uncertainty in looking so far into the future when talking about software. But I believe that between now and 2065, the pressure to support code as data will be so strong and obvious that there will be standards and language additions well beyond things like eval() and the Java script-engine. That is, the environment for code as data processing will become much richer. I'm also optimistic that the XML concept will continue its popularity for quite a while. Those two factors suggest an adaptation.
XPL today is really fast but XPL + XML processing includes some duplication of functionality. The XPL Parser separates tags from text and tag names from attributes. Those are fed into XML processors without the XML parser knowing what's coming at it, so it does this same parsing again. It would seem to make sense to have a single parser that can do it all. But then it wouldn't be just for markup, so the name eXtensible Markup Language would need to be changed. The other side of the argument is that both XPL and XML processing are very fast and computers are fast now, and will continue to get faster, so who cares? I always have and probably always will. We'll always have reasons to want more speed. If everybody was me, the changes would already have been made. :)