Re: calling for xproc pain points, requested features, etc

Would it be too scary to simply make the port names resolve against the 
nearest definition in an enclosing pipeline?  IE - make the port names 
"tunnel" like xslt params can?  Or maybe provide an option since that 
could break existing code, probably.

-Mike

On 01/05/2012 11:32 AM, Philip Fennell wrote:
> Perhaps rather than suggest names, I should describe the use cases for referencing specific pipeline/step-declarations that shouldn't need naming explicitly because their context in relation to the 'current' step is clear by way of element ancestry:
>
> 1) I want a token to refer to the step-declaration that 'contains' the 'current' step so I can access its inputs.
>
> 2) I want a token to refer to the outer most (root) pipeline/step-declaration so I can access its inputs.
>
> There may be situations where (1) and (2) are the same thing but I think in that instance the either token would be acceptable.
>
>
> Regards
>
> Philip
>
> -----Original Message-----
> From: Geert Josten [mailto:geert.josten@dayon.nl]
> Sent: Thursday, January 05, 2012 3:09 PM
> To: Philip Fennell; James Fuller; XProc Dev
> Subject: RE: calling for xproc pain points, requested features, etc
>
> Nice idea! #current doesn't make much sense, but perhaps something like
> #previous would?
>
> Kind regards,
> Geert
>
> -----Oorspronkelijk bericht-----
> Van: Philip Fennell [mailto:Philip.Fennell@marklogic.com]
> Verzonden: donderdag 5 januari 2012 15:58
> Aan: James Fuller; XProc Dev
> Onderwerp: RE: calling for xproc pain points, requested features, etc
>
> My favourite gripe is that you have to explicitly name a step in order to
> refer to any of its inputs from a p:pipe instruction within that step.
>
> Would it be possible to have the concept of #current or #parent as the
> reference to the step declaration you are in. This would be similar to
> XSLT 2's #current mode.
>
> I think it would go something like this:
>
>
> 	<p:declare-step type="some:step">
> 		<p:input port="source" primary="true"/>
> 		<p:input port="other" primary="false"/>
> 		<p:output port="result"/>
> 		
> 		<p:add-attribute match="c:request" attribute-name="href">
> 			<p:with-option name="attribute-value"
> select="/html:link/@href">
> 				<p:pipe port="other" step="#parent"/>
> 			</p:with-option>
> 		</p:add-attribute>
> 	</p:declare-step>
>
>
> Probably #current is not a good name because in the above example the
> 'current' step is p:add-attribute but its 'parent' step is the some:step
> declaration.
>
>
> Regards
>
> Philip
>
>
>
> -----Original Message-----
> From: James Fuller [mailto:james.fuller.2007@gmail.com]
> Sent: Thursday, January 05, 2012 1:22 PM
> To: XProc Dev
> Subject: calling for xproc pain points, requested features, etc
>
> As we review where we go from here with xproc.vnext can I ask people
> on this list to comment on;
>
> * highlight their top 4-5 pain points using XProc from a usability
> perspective. We have captured some of these here;
>
>       http://www.w3.org/wiki/Usability
>
> * expand on what you think maybe useful for xproc.vnext, once again we
> have captured some of this here
>
>      http://www.w3.org/wiki/XprocVnext
>
> * comment on expectations for timelines on an xproc.vnext as well as
> highlighting key priorities e.g. is this is a short 'fix whats broke'
> or something more 'revolutionary' ?
>
> appreciate everyone taking time and effort on this.
>
> Jim Fuller
>
>

Received on Thursday, 5 January 2012 18:54:05 UTC