Upcoming - xmlsh docs in docbook

Thanks to some excellent mentoring, great patience, and help from Dave Pawson (including a start at a Wiki-docbook converter), I've decided to embark on converting the xmlsh docs to docbook format.

I'm going to start with the hard one, the command "man page" documents, and go from there. Advise and volunteers welcome !

sourceforge ... why ?

When I frst started xmlsh I chose Sourceforge for hosting. Why ? I admit one of the main reasons was a sense of 'legitimacy'. It seemed to me all the "Good" Open Source projects were on sourceforge. (of course so are a lot of "Bad" ones) ... but by picking Sourceforge I felt people might "trust" the open source nature of the project then say by hosting it on my own server. Until recently, for example, SF refused to let you delete files. Thats a good thing right ? you cant retract your project once its published. Your making a commitment to Open Source by being on Sourceforge. Right.

I also thought I might use some of SF's collaborative features such as Wikki, bug tracking, groups etc.

Well 2 years later and I'm less enchanted. SF is seriously thrashing. For the last 2 weeks I've only intermittantly been able to checkin to svn. The analitics is spotty, sometimes works sometimes doesnt. I dont use the Bug Tracking (and neither do my users). Noone's subscribed to the mailing list or used the forums. And ... its getting slower and more ad-laden every day. If you click to download you're forced to view a 20+ second ad before you can download. Not that I'm complaining ... for a "free" service what do I expect ?

But this last trouble with SVN is bothering me. I found several other open tickets with the same error report over 3 weeks old. It seems SF is collapsing from its own weight and maybe I better abandon the ship before the last rat beats the captin. Or maybe "really soon now" its going to turn into the awsome site it once was ...

Do I hold my breath or jump ship ?
Do people really think as I thought that SF adds a sence of "legitimacy" to an OS project ?

Is it worth the fact it doesnt work and their tech support isnt supporting ?

Curious minds want to know.

xmlsh extension functions in xpath/xquery/xslt

Thanks to Kurt Cagle for the suggestion, I've implemented extension functions in xpath/xquery/xslt and the builtin <[ ... ]> notation.

The one function is "eval". This allows you to call into xmlsh from within any xpath expression and return the result (stdout) of the command back.
Right now I have set it so you have to manually declare the namespace, saxon style.
Examples:


declare namespace xmlsh=java:org.xmlsh.xpath.XPathFunctions
xecho <[ xmlsh:eval("xecho $*" , ("foo" , <bar/>, 1 ) ) ]>
xquery -n 'xmlsh:eval("xls")'
xpath -n 'xmlsh:eval("xls $*" , "*.xml")'
var=<[ xmlsh:eval("xls") ]>



I think this is an extremely useful feature (thanks to Kurt for suggesting it !), and I want to make it easier to use by not requiring the "declare namespace". But, I don't want to impose magic namespaces into code that isnt expecting it. Also doing this globally results in a namespace declaration in the output (which is being stripped out by the serialization process but is still there under the hood).

To solve the first problem, I'm thinking of building in the 'declare namespace' part into the <[ ... ]> syntax only and leaving it up to the user to decide to import the extension functions themselves for explicit calls to xquery/xpath/xslt.

I'm not sure how to solve the second problem, although it is largely an invisible one. I was reading on the saxon docs and the suggestion was to do the namespace declaration in the preamble of xquery itself rather then externally to avoid extraneous namespace declarations resulting in the output. Thats what I'd do for the <[ ...]> but maybe I should leave it up to the user to do that their own way for an explicit call to xquery/xslt/xpath.

As for the namespace prefix ... there's a convention of using "ex" for extension functions so maybe I should pick "xmlshex" although thats getting long, or just "ex" ... opinions welcome !

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"