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

On Mon, Dec 8, 2008 at 3:21 PM, David A. Lee <dlee@calldei.com> wrote:
> Am I misreading things ?
> I dont think its "legal" to change the default binding in an implementation
> specific way,
> if its in violation of the specs.  The specs clearly say the binding is the
> "default readable port".
> I'm going to "do" it but it wont be "legal".
>

fair enough, but you are able to add extension attributes e.g. 3.8
Extension attributes ... which you can then use to subvert all manner
of XProc behavior (which is illegal!).

> When I get further along in the implementation I will indeed take you up on
> that idea of sending more test cases.


good stuff.

> However in this case, I cant even imagine a useful case where this case
> would be used,  Which is one reason I'm objecting.
> Plus if my implementation can "pass" the tests while I know myself its
> "broken" because I am not going to implement this part,
> why should I submit a test case to "break" it :)

yes, you are right, but it would be nice to have any test cases that
characterize weaknesses in streaming.

in any event, I would at least add an extension attribute to turn on /
off the default illegal behavior.

gl, Jim Fuller

> -David
>
>
>> 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 14:30:15 UTC