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

Hello David,

Perhaps at this very late stage something could be added to define the
default binding, in fact you can do this yourself as an extension to
xproc quite legally.

Streaming is a form of optimization and I think that XProc did
potentially too much 'early optimization' type thinking throughout
discussions on the spec. Lets be confident that we will discover the
ways later on to inform a v2 ... e.g. if people use it, it will no
doubt find its way into later/future versions.

btw, as an implementator you will benefit from existing test cases and
I would say why not submit representative missing test case u mention.

cheers, Jim Fuller





On Mon, Dec 8, 2008 at 2:39 PM, David A. Lee <dlee@calldei.com> wrote:
> 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.
>
> A summary of my objection is that in my opinion, as a implementer of the
> xproc standard,
> that this prevents a conforming xproc implementation from potentially
> streaming through
> any action that uses any parameters or options specified with p:with-option
> and p:with-param
> because the processor would have to collect (fork and buffer) the input for
> use by the select
> attribute prior to starting the action, even if the xpath expression did not
> reference any context.
> In my opinion, the advantage to the user for this convenience is far
> outweighed by the cost
> to the implementation.  In fact the current test suites do not have a single
> case where the context
> is actually used.   By coding this into the specs it is placing an extreme
> burden onto future implementations
> and onto the potential performance of any future implementations, with , in
> my opinion, little or no value to
> xproc pipeline authors.
>
> In my implementation of xproc I intend on not implementing this portion of
> the spec due to these concerns.
>
> Note there was an alternative suggested for implementers, which is
> performing full static analysis of the xpath option
> to determine if a context is referenced.    I suggest this is an undue
> amount of effort required for implementers of this
> specification, considering a goal of the spec is to allow implementations to
> reuse existing standard libraries which do
> not have this capability. A simple change to the spec would eliminate this
> burden while not having a significant
> impact on usefulness to pipeline authors.
>
>
> Please refer to threaded discussions in the XProc mailing list
>
> http://lists.w3.org/Archives/Public/xproc-dev/2008Nov/0055.html
> http://lists.w3.org/Archives/Public/xproc-dev/2008Dec/0011.html
>
>
> Thank You.
> -----------------------------------------------------------
> David A. Lee,
> President DEI Services Inc.
> dlee@calldei.com
> http://www.calldei.com
> http://www.xmlsh.org
>
> ----------------------------------------
> David A. Lee
> Senior member of the technical staff
> Epocrates, Inc.
> dlee@epocrates.com
>
> ------------------------------------------------
> David A. Lee
> CTO
> Nexstra, Inc.
> dlee@nexstra.com
> www.nexstra.com
>
>

Received on Monday, 8 December 2008 13:49:17 UTC