RE: Immediate Market Needs for XProc

I like where you're going with this Kurt.

I'll toss into the mix another, related idea...

Perhaps there should be a generic event step, analogous to p:exec?

Where p:exec enables you to invoke any command, a generic event step would enable you to institute any kind of event structure (I realize that I'm being vague here, I am not an expert on events, but I'll bet there are people on this list who are).

/Roger 


________________________________

	From: Kurt Cagle [mailto:kurt.cagle@gmail.com] 
	Sent: Sunday, May 10, 2009 1:09 AM
	To: James Fuller
	Cc: Costello, Roger L.; xproc-dev@w3.org
	Subject: Re: Immediate Market Needs for XProc
	
	
	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 12:29:37 UTC