Re: Objection to XProc: An XML Pipeline Language section(s) 5.7.3, 5.7.4

"David A. Lee" <dlee@calldei.com> writes:
> I would like to formally object to the following sections of the
> XProc: An XML Pipeline Language specification, W3C Candidate
> Recommendation 26 November 2008
>
> Sec 5.7.3 p:with-option
> Sec 5.7.4 p:with-param
>
> The objection is to the default binding of the context for the
> select= attributes, which in these sections are defined to be the
> default readable port. I propose that the default binding should be
> <p:empty/> unless explicitly bound.

Dear David,

The XProc WG considered[1] your comment and came to the conclusion
that it favors the status quo.

We make the following observations, in no particular order:

1. The shortcut syntax is the preferred method for setting options to
   simple values. When the short cut synatax is used, there can be no
   reference to the context.

   When the shortcut syntax can't be used, it's either because the
   expression does refer to the context (in which case, the implementation
   is stuck providing it) or because it's an expression over constants
   and variables.

   While it's undeniably the case that a perfect analysis of which is
   which might require a full XPath 2.0 parser, it seems equally to be
   the case that a much simpler analysis might catch the vast majority
   of real-world cases.

2. Everywhere else in the spec, where there's a possible binding and that
   binding isn't specified, the default readable port is used automatically.
   Changing the rules for p:with-option and p:with-param would introduce
   an inconsistency that some members of the WG would find odd.

3. If we did make the change you proposed, it would impose a much
   larger burden on pipeline *authors* when they did want to make
   reference to the context.

   Consider this pipeline:

   <p:pipeline>
     <p:label-elements>
       <p:with-option name="attribute" select="'myId'"/>
     </p:label-elements>
   </p:pipeline>

   Arguably, it requires the implementation to provide a binding to
   the option, even though it's never used (though the implementation
   could easily detect this case and avoid it). If the author changes
   the pipeline so that the context is needed, the change is simple
   and straightforward:
   
   <p:pipeline>
     <p:label-elements>
       <p:with-option name="attribute" select="/*/@myIdName"/>
     </p:label-elements>
   </p:pipeline>

   Under your proposal, the former example would work, but the latter example
   would fail because there'd be no context for the expression. In order
   to fix that, the author would have to (1) understand why the error arose
   and (2) change the pipeline rather significantly:

   <p:pipeline name="main">
     <p:label-elements>
       <p:with-option name="attribute" select="/*/@myIdName">
         <p:pipe step="main" port="source"/>
       </p:with-option>
     </p:label-elements>
   </p:pipeline>

   This seems like a significant burden to place on authors.

The WG appreciates your concerns and understands that the choices made
in the status quo increase the burden on implementors, but we aren't
convinced that the change you propose would be a net improvement.

If you remain unsatisfied, please let us know and we'll care your
formal objection forward through the process. If, on the contrary,
you're persuaded to drop your formal objection, please let us know
that as well.

Norman Walsh,
On behalf of the XProc WG

[1] http://www.w3.org/XML/XProc/2008/12/11-minutes.html#item06

-- 
Norman Walsh <ndw@nwalsh.com> | Growth for the sake of growth is the
http://nwalsh.com/            | ideology of the cancer cell.--Edward
                              | Abbey