RE: [ANN] XProc Graphical Editor

Hi Leif,
 
This is excellent news. Good to hear more people are working on XProc
editors; XProc really needs user-friendly tools.
 
Regarding your question about the e:type attribute: I think it should
work, but perhaps using p:pipeinfo would be more according to the spec?
(For instance, our designer uses p:pipeinfo elements for storing layout
information.)
 
Regards,
Vojtech


________________________________

	From: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org]
On Behalf Of Leif Warner
	Sent: Thursday, July 16, 2009 8:12 AM
	To: XProc Dev
	Subject: [ANN] XProc Graphical Editor
	
	
	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