W3C home > Mailing lists > Public > xproc-dev@w3.org > July 2009

[ANN] XProc Graphical Editor

From: Leif Warner <abimelech@gmail.com>
Date: Wed, 15 Jul 2009 23:12:09 -0700
Message-ID: <54d4ec0f0907152312n32968708q1cb1da287324b77d@mail.gmail.com>
To: XProc Dev <xproc-dev@w3.org>
Hey, I've got a preliminary XProc editor running online to play with:

http://feedscape.appspot.com/

Even as a hard-core command-line nut, learning XProc and writing pipelines
seems a lot easier this way (though you'd probably want to further edit the
results to get the full generality).
Of course gobs of features are missing at this point.  You can fake the
select statments on input ports with a p:filter, and the p:document for an
input port with a p:load.

Some things I had planned were file-upload forms attached to p:document
inputs, so docs on your local machines would get a URL under your name on
there, incremental processing (like Yahoo Pipes, so you could see the output
of your pipe thus far constructed), and loading whatever libraries you want
into the editor.
Speaking of that last feature, would XProc processors be ok with the
libraries having an extra 'e:type="xsd:boolean"' attribute on the option
descriptions, like in http://www.w3.org/TR/xproc/langspec.xml, or perhaps
some comments, to indicate what kind of forms to make in the interface?
I want to have an XML DB on the backend, too; i.e. for caching search
results, feeds, what have you.

The idea came about as a suggestion by the local data plumber's group [1] to
have an open-source alternative for Yahoo pipes; I thought XProc would fit
the bill nicely.  Also they presented the WireIt library as a possible GUI
for this.  It already had most of the data types nessesary for option values
(no XSLTMatchPattern or anything yet, though), and all I had to do was write
an XSLT stylesheet to turn the XML version of the XProc spec into a JSON
language description for the WireIt wiring editor.  And figure out how to
make Calabash run on Google App Engine inside a servlet.

Speaking of calling Calabash from other apps, anyone else have any
experience to share in doing so? (e.g. with David A. Lee's xmlsh?)
I was thinking it might be nice to have a "driver" or something in Calabash
to offer a more simple API interface of just "runPipeline(inStream,
outStream)" or "runPipeline(xdmNode, xdmNode)", etc...
I had to hack com.xmlcalabash.util.URIUtils to return things other than
file:// URLs for things like base URLs (that was a Google App Enginge
specific necessity, as GAE does NOT like you touching files), and I overrode
com.xmlcalabash.io.WritableDocument to ennable you to pass in an arbitrary
OutputStream, rather than having System.io.Outputstream hard-coded in.

Comments, suggestions, help...  (See also the EMC one just out)
-M. Leif Warner

[1] http://groups.google.com/group/portland-data-plumbing
Received on Thursday, 16 July 2009 06:12:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 16 July 2009 06:12:56 GMT