- From: Geert J. <geert.josten@dayon.nl>
- Date: Wed, 19 Feb 2014 07:58:28 +0100
- To: Florent Georges <fgeorges@fgeorges.org>, Romain Deltour <rdeltour@gmail.com>
- Cc: XProc Comments <public-xml-processing-model-comments@w3.org>, XProc Dev <xproc-dev@w3.org>
+1 from me on the general idea as well. It is in line with twitter feedback to the callout by Jim Fuller about v2 reqs.. :) > -----Oorspronkelijk bericht----- > Van: fgeorges@gmail.com [mailto:fgeorges@gmail.com] Namens Florent > Georges > Verzonden: dinsdag 18 februari 2014 16:55 > Aan: Romain Deltour > CC: XProc Comments; XProc Dev > Onderwerp: Re: an idea: ports == options > > Hi Romain, > > I think you got it right! From a user point of view at least. Now > the working group and implementers will hopefully look at it, from the > point of view of graph connections analysis. > > But it looks great to me! > > Regards, > > -- > Florent Georges > http://fgeorges.org/ > http://h2oconsulting.be/ > > > On 16 February 2014 13:02, Romain Deltour wrote: > > Hi, > > > > Just an idea for XProc v2 (or v4?): > > > > TL;DR: A proposal to "merge" the concepts of ports and options (an > options == a port), while still enabling static dependency graph analysis. > Based on the possibility to bind readable ports to variables available in the > in-scope bindings of a step. > > > > Caveat: this is a pretty long read. > > > > ## Rationale > > > > XProc v2 will allow arbitrary XDM values in variables and options [1]. This > blurs the line between options and ports, both will accept sequences of > documents, or as likely in v2, any XDM. The primary difference is that ports > can be *connected*. > > But, if there was a way to consume a step result from the XPath > representing an option's value, that would essentially mean that output > ports can be connected to options. In other words, it kind of erases all the > conceptual differences between ports and options. > > > > About a year ago, it was suggested to use a *function* (say 'p:read-port') > to access ports from XPath expressions [2]. This idea was not accepted as a > v2 req based on the very legit grounds that the static analysis of the XProc > graph would become impractical [3]. > > > > What I'm considering below is to use another mechanism to make > readable ports available to XPath expressions, not using a function but > rather externally binding readable ports to variables. > > > > ## Proposal > > > > 1. First, assume that there are no longer differences between input ports > and options. An input port is an option, an option is an input port. > > > > 2. Introduce a declarative way to bind a readable port to a variable, added > to the in-scope bindings of the Environment. This could be done with a new > element, say "p:bind", with a required "name" attribute (the name of the > variable), and either a "step" and "port" pair of attributes (to bind the > variable to a readable port) or inline content. > > > > 3. The options / ports are set by XPath expressions, the previously defined > variables being available from the static XPath context. > > > > ## Connections > > > > (adapted from the examples in the XProc spec "Associating Documents > with Ports" [4]) > > > > ### Specified by URI > > > > Would be done with fn:doc. > > > > <p:identity source="doc('http://example.com/input.xml')"/> > > > > ### Specified by Source > > > > Declaratively bind the source to a variable with the p:bind element, then > use this binding in the option declaration (see more of the nitty-gritty in the > later section below). > > > > <p:xinclude source="$source"> > > <p:bind name="source" step="other" port="results"/> > > <p:xinclude> > > > > ### Specified inline > > > > Use the p:bind element with inline content. > > > > <p:xslt stylesheet="$stylesheet"> > > <p:bind name="stylesheet"> > > <xsl:stylesheet version="1.0">...</xsl:stylesheet> > > </p.bind> > > </p:xslt> > > > > ### Specified explicitly empty > > > > Use an empty attribute, or the empty sequence. > > > > <p:xslt source="" stylesheet="doc('stylesheet.xsl')"/> > > > > ## Nitty gritty of the "port" connections > > > > ### Implicit connections > > > > An important and convenient feature of port connections in v1 is the > concept of primary ports and default connections. Similarly, one option in > the signature could be annotated as the "primary" option, which would be > automatically bound to the default readable port. That would keep looking > like that: > > > > <p:identity/> > > > > being equivalent to > > > > <p:identity source="$source"> > > <p:bind name="source" step="previous-step" port="primary-output"/> > > </p:identity/> > > > > Another possibility is to reserve the $default variable to automatically bind > it to the default readable port: > > > > <p:identity source="$default"/> > > > > ### Variable overrides > > > > You'll asks: What about existing variables from the in-scope bindings ? Is > there a risk to override them ? > > Well, the idea is that yes, p:bind overrides previous variables. > > > > For instance in: > > > > <p:variable name="source" value="'blahblah'/> > > <p:identity source="$source"> > > <p:bind name="source" step="previous" port="result"/> > > <p:identity/> > > > > the source option would be bound to the result of the previous step, the > variable source is overridden in the in-scope bindings. > > If you want to keep using that variable, there's still the option of using > another name for the port binding: > > > > <p:variable name="source" value="'blahblah'/> > > <p:identity source="$my-source"> > > <p:bind name="my-source" step="previous" port="result"/> > > <p:identity/> > > > > ### Implicit options > > > > It might be useful to implicitly set options if there is a variable of the same > name in the in-scope bindings. For instance: > > > > <p:identity> <!-- the source option is implicitly set --> > > <p:bind name="source" step="previous" port="result"/> > > <p:identity/> > > > > ## More complex examples > > > > Logging the count of flowing documents using a potential p:message step > of v2: > > > > <p:message source="$source" message="'number of docs: ' || > count($source)"> > > <p:bind name="source" step="other" port="result"/> > > </p:message> > > > > or, possibly with a reserved $default variable and implicit connections: > > > > <p:message message="'number of docs: ' || count($default)"/> > > > > (note: $default is bound to the default readable port by convention, > @source is declared in the signature as the primary option so it's implicitly > connected to the default readable port). > > > > Try that with XProc v1 :) > > > > That's it! I've probably overlooked a bazillion things, but just wanted to > throw the idea while it's fresh. Comments welcome! > > > > Romain. > > > > [1] http://www.w3.org/XML/XProc/docs/xproc-v2-req.html#aribrary-vars > > [2] http://lists.w3.org/Archives/Public/xproc-dev/2013Feb/0028.html > > [3] http://lists.w3.org/Archives/Public/public-xml-processing-model- > comments/2013Sep/0001.html > > [4] http://www.w3.org/TR/xproc/#syntax-docs-ports
Received on Wednesday, 19 February 2014 06:59:14 UTC