Sunday, August 23, 2009

XML representation of xmlsh script

A year ago at Balisage an attendee thought of something I had never considered. When hearing I was giving a talk on an "xml shell language" his immediate thought was that the scripting language itself would be in XML. One of my primary reasons for xmlsh is that I don't personally enjoy writing XML for command languages, especially interactively. I dont want to write
<command name="ls"><arg>*</arg></command>
when I could type
ls *

I think xproc and xslt are great example of using xml itself as a programming language. They have many great features, but one of them doesn't include ease of writing or reading (imho). Especially interactdively.

A goal of a shell is that it works equally well as a interactive command language, and as a (file based) script language.
So I never once considered using XML as the language for xmlsh.

Shame on me, since as stated in my Philosophy page I am hoping XML is used for everything. I guess I mean everything *except for xmlsh itself*.
Hows that for hypocritical.

In hindsight, seeing the success of xproc, I have to realize that there are advantages in an XML form for scripting languages. While I certianly dont want to *author* a script in XML, atleast interactively, there are advantages to having a form of the script in XML. These include

* Easier output by programs - geting the syntax exactly right is easier in XML
* Ability to transform - apply XSLT to the script
* Easier to store and manipulate using XML such as an XML DB
* Easier to parse

A direct example of the above is that getting my xproc-to-xml translator may be easier if I could output an XML version of an xmlsh script instead of the text version. Getting things like where spaces and newlines are allowed exactly right is tedious for a processor. ( usually "obvious" for a human ).

So is there value in an XML representation of an xmlsh script ?
Maybe.
Is it easy to implement ?
Maybe. I fully compile the text using javacc into an intermediate tree format before executing. This tree format could come from XML parsing instead.

Is it worth doing ?
I dont know. I could use opinions.
Would anyone else find value in this ? This would be equivilent to creating an XML syntax for xquery, such as XQueryX
But likewise, I've never heard of this actually being used by anyone.
( but I know my ignorance isnt a true representation of fact )
It would probably end up with the same kind of verbosity as XQueryX and
Quote: "The result is not particularly convenient for humans to read and write"
Posted by at 5:14 AM
Labels:

3 comments:

  1. Relax NG is a good example. Has both an XML format
    and a 'simpler' format?

    The XML format may be generated by such as XSLT,
    the 'other' format is easier for humans.

    Both are useful. JC even provided a tool to transform one into another.

    So yes, I guess the XML format is useful!

    HTH DaveP
    ReplyDelete
  2. Dave Pawson beat me to it. Authoring in the RNC non-XML format is much better for a human, but having the ability to convert to XML opens up the whole XML ecosystems of tools.

    Ant uses an XML syntax, but it's not great to author, and a JavaScript-like or Python-like syntax would be better to author the script in, and as long as they translate with full fidelity to XML (with proper error lines conversions).

    Just like in XML, what really matters is the *info-set* and the actual format used is relevant to the parser/tool only, not human being.

    The advantage of having an XML representation of the "info-set" is to:
    1) contains lots of meta-data, similar to how the AST of a C++ source file tells you a lot more about the code that what just looking at the source tell you (calls to implicit conversions, type coercion, etc...)
    2) ability to transform / validate using XML tools.

    Another analogy is with Lisp, with the code and the data using the same syntax, allowing to write code (macros) that "write" code.

    If XMLSH had an XML syntax, you could have XMLSH "code" that generates XMLSH "code" based on XML "data" that furthers processes more XML "data".

    Hopefully that makes sense ;-)
    ReplyDelete
  3. Makes perfect sense. You can actually do that today but not with XML tools. The xproc2xmlsh tool I've been working on is exactly that (takes xproc xml input as data, uses xmlsh to produce xmlsh output)

    But yes I could see how having an XML syntax could be useful. But would anyone use it ? Wont know until I try it :) Is anyone using XQueryX ?
    Do the authors think it was worth the effort ? I don't know.

    Thanks for the comments !
    ReplyDelete

Due to comment spam, moderation is turned on. I will approve all non-spam comments.

Subscribe to: Post Comments (Atom)