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

Re: [ANN] XProc Graphical Editor

From: Norman Walsh <ndw@nwalsh.com>
Date: Fri, 17 Jul 2009 14:15:13 -0400
To: XProc Dev <xproc-dev@w3.org>
Message-ID: <m27hy7yy4u.fsf@nwalsh.com>
Leif Warner <abimelech@gmail.com> writes:

> Hey, I've got a preliminary XProc editor running online to play with:
> http://feedscape.appspot.com/

Very cool!

> 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.

Extension attributes should be fine. I guess I should drop this into
exproc.org so we can all do it the same way.

My implementation actually takes an augmented format as its input for
the standard steps:

<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: typed-pipeline-library.xml,v 1.48 2009/05/26 19:41:26 NormanWalsh Exp $ -->
<p:library xmlns:p="http://www.w3.org/ns/xproc"
   <p:declare-step type="p:add-attribute" xml:id="add-attribute">
      <p:input port="source"/>
      <p:output port="result"/>
      <p:option name="match" required="true" cx:type="XSLTMatchPattern"/>
      <p:option name="attribute-name" required="true" cx:type="xsd:QName"/>
      <p:option name="attribute-value" required="true" cx:type="xsd:string"/>

> 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)",

I definitely plan to provide and document a simple(r) API for calling

> 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.

Ah. That's the sort of feedback I need for such an API.

                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com> | Every new beginning comes from some
http://nwalsh.com/            | other beginning's end.

Received on Friday, 17 July 2009 18:15:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:16:48 UTC