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

Re: Immediate Market Needs for XProc

From: Kurt Cagle <kurt.cagle@gmail.com>
Date: Sat, 9 May 2009 22:08:59 -0700
Message-ID: <6fa681b10905092208o193e5552m6bd5a50d35f3dd68@mail.gmail.com>
To: James Fuller <james.fuller.2007@gmail.com>
Cc: "Costello, Roger L." <costello@mitre.org>, "xproc-dev@w3.org" <xproc-dev@w3.org>
James,

True. I'd rather lost track of the fact that this is the key mailing list
for eXProc - way too may e-initiatives right now.

In the spirit of that, let me make a more fully proposal:

*pxp:xforms-input
*
A step for receiving user xforms input as part of a pipeline.

<p:declare-step type="pxp:xforms-input">
     <p:input port="source" primary="true"/>
     <p:input port="xforms"/>
     <p:output port="result"/>
     <p:option name="wait-interval" select="0"/>               <!-- xs:double
-->
   <p:option name="source-url"/>
   <p:option name="target-url"/>
   <p:option name="option" select="'method=xml
media-type=applications/xhtml+xml'"/>
</p:declare-step>
This step will cause the process to go to sleep until one of two events
happen - either the user submits a given XML structure for input from a
generated XForms instance, or the wait-interval duration in seconds is
exceeded. If the result output is not a well-formed document, a malformed
document error will be returned. If the wait-interval is exceeded, a timeout
error will be returned. If the wait-interval is not specified, then this
will default to the timeout option of the server itself.

The xforms-input step would be used to return an XForms document to the
client in a client/server application, at which point the pipeline is put to
sleep, when the submitted content gets returned (if within the
wait-interval), then the pipe picks up where it left off, passing the
received document as the result of the step.

The target-url will be the URL to be passed into the XForms as the
submission URL of the Xforms itself. The source will be an initial template
to be passed as the initial model instance if provided. If not, the
source-url will be a URL pointer to the XML source for the XForms itself. If
no input source is provided, a source-url must be provided and vice versa,
and both cannot be provided within the same step. The step will overwrite
the first instance in the first model unless there exists a model instance
stub named "source", in which case this will be overwritten as appropriate.

The *option* option (unfortunate name, but consistent) sets up the XSLT
options (or XQuery declare options field) for the generation of the form
itself, not the result.

(This is a very ad hoc proposal, and I highly welcome recommendations on it,
including even whether it is necessary or feasible).

Kurt Cagle
Managing Editor
http://xmlToday.org


On Sat, May 9, 2009 at 9:06 PM, James Fuller <james.fuller.2007@gmail.com>wrote:

> these are all good candidates for www.exproc.org.
>
> ta, J
>
> On Sun, May 10, 2009 at 4:18 AM, Kurt Cagle <kurt.cagle@gmail.com> wrote:
> > This might also be a little controversial, but what about human workflow
> > steps? Something like a <p:wait/> or <p:user-input/> step that will hold
> the
> > processor in a holding pattern until some kind of response is received. I
> > could see this especially in a setup that generates an XForms for input.
> >
> > Kurt Cagle
> > Managing Editor
> > http://xmlToday.org
> >
> >
> > On Sat, May 9, 2009 at 4:12 PM, Costello, Roger L. <costello@mitre.org>
> > wrote:
> >>
> >> Hi Leif,
> >>
> >> > I've been working on an XProc GUI using WireIt [1].
> >>
> >> Great! I'm eager to see it when you have it ready.
> >>
> >> > Is the configuration management tool similiar
> >> > to a version control system
> >> > (i.e. git, svn, etc)?
> >>
> >> Yes, that's what I was thinking.
> >>
> >> > I was thinking it would be nice to have a central directory of XProc
> >> > libraries that encapsulate web service APIs.  Yahoo recently put a
> >> > user-contributable directory of web service wrappers up on github for
> >> > use
> >> > from YQL [2].  They specify the URL and input parameters (required or
> >> > optional), but don't seem to say much about the output of the web
> >> > services
> >> > (arguably much more complicated).
> >>
> >> > Maybe say, I'd want a bus arrival step (that encapsulates my transit
> >> > service
> >> > api), and later on some info from that could go into a mapping step...
> >>
> >> Great idea!
> >>
> >> /Roger
> >>
> >> > [1] http://javascript.neyric.com/wireit/
> >> > [2]
> >>
> >>
> http://www.javarants.com/2009/02/05/yql-opens-up-3rd-party-web-service-table-definitions-to-developers/
> >>
> >> > -Leif Warner
> >
> >
>
Received on Sunday, 10 May 2009 05:09:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 10 May 2009 05:09:44 GMT