State of XProc: language and community

I compiled a few thoughts I have had over and over again recently.  I’m sharing them with the list as feedback for the entire XProc ecosystem.  

Do with the feedback what you will.  Flame me.  Delete it.  Respond.  Pass it onto others.  If nobody ever reads this message, at least I wrote it down so that I can get it out of my head.  ☺  

In any case, I welcome feedback and discussion on any of this.  Don't be shy!  ;-D


XProc LANGUAGE

Needs better separation. 
There's a striking lack of separation between the plethora of things that (may or may not) appear at the beginning of a step—such as ports, options, and so on—and sub-pipelines and contained steps.  

Maybe I'm just used to the head/body pattern from HTML.  But I can't help but imagine that something similar might be beneficial for XProc.

Needlessly redundant steps. 
Many separate p:validate-with-* steps exist when a single p:validate step with something like @with="relax-ng"  would suffice. This needlessly adds to language bloat IMO.

Lack of syntactic sugar.
There are so many times when the most common use case has to be written and re-written over and over again.  This drives me absolutely crazy and significantly increases the size of my code. The XProc wiki (http://wiki.XProc.org/XProcVNext) outlines this—and a number of other syntactic sugar enhancements—that would make XProc so much more pleasant.  

Data types. 
XProc’s lack of built-in data types can be unbelievably frustrating.  And XML is designed for modular reuse—including plenty of data types that have been battle-tested for years.  If XProc supported even just a tiny subset of these, it would make life so much easier. 

At the very least, I think XProc should know the difference between a document, a URI, and a string. 

While we're at it, it would be extra awesome if data types were usable directly inside attributes instead of  having to nest like <p:with-option … />. This could easily be accomplished without ambiguity for processors by making use of XPath's built in functions, e.g. string(‘aaa’), base-uri(‘http://weee/subdir/‘), and so on.  (Constructor Functions for XML Schema Built-In Types seems worth a quick review here.)


XProc COMMUNITY 

Documentation. 
I love Calabash!, …but the lack of documentation is a real downer.  It even resulted in quite a shock for me when I discovered there was a mechanism for providing Calabash with custom settings.  I’d been using Calabash for months at the time, and had no idea this was even possible.

It would also be great if there was something with the same role as Javadoc for XProc.  (I.E., Parse XProc files and output human-friendly documentation in XHTML [or whatever]).  

Documentation—that is, good documentation—unites people and fosters collaboration.  We need more of it.

Un-unified community efforts. 
One of my favorite things about XML community is how active it is.  Members are very supportive each other.  And there seems to be a delightful absence of the “elitist jerk programmer” stereotype mindset.  If I didn’t know any better, I might think most of us really love this stuff, and enjoy that others love it, too!  ;-)  

However, although the discussion lists are quite healthy, solutions are scattered. People come up with great solutions…and they might tell the mailing list about them.  They might even post them on the web.  But there is no central place to share solutions.  

Common recurring problems may have a dozen independently-created solutions to them, all created by different people.  At the same time, other programmers may not be as skilled, and become frustrated in searching for a solution and give up. 

For example: 
Norm’s online XProc Book has a fully-functional ex:recursive-directory-list step.  It’s written in XProc itself, so it’s even processor-independent.  Cool!  

…So, why isn’t this brilliance on EXProc.org?  

The closest thing to a central place for this stuff is the XProc wiki…but activity remains almost nonexistent here. 

The EXPath Project also aims to be a central space for collaboration.  It embodies my vision of what the XML community needs most.  …But although it’s slightly more populated with content than the XProc wiki, it appears to have been on hiatus for at least a couple of years.  (I’m trying to begin contributing to this project in the hopes of getting some momentum going again.  Fingers crossed!)

Seriously, everybody: we have an amazing, brilliant, inventive, helpful, and (on mailing lists at least) active community.  We just need to focus all that talent on pooling our resources!  

It would be so very, very glorious.  

Norm. 
I love you Norm!  (strictly professionally of course! ☺)  I think that if anyone else attempted to do as much as you, their head would probably explode. 

However, there are have been many occasions—far too numerous to recall—where I wanted to contribute something to the websites for XProc, Calabash, and EXProc…but I wasn't able to. 

Aside to Norm:
I did try writing you personally, writing the mailing list, and even leaving a note for you on the XProc wiki hoping you might notice.  Alas, no such luck.  I figured it would take more than that for little ol’ me to register on your very busy radar, but I had to try. 

No hard feelings!  Just a disclaimer. ☺

…Meanwhile, the wiki goes pretty much untouched.  So there’s a wiki with maybe one page of useful info that is dead in terms of activity, and there’s plenty of useful pages on the xproc.org / xmlcalabash.org / exproc.org sites, but they are pretty much dead in terms of activity (with the exception of Calabash releases).  

I really wish there was a way this stuff into the hands of our awesome community…but right now there is no such space.  ☹  


—Tony