- From: David A. Lee <dlee@calldei.com>
- Date: Mon, 8 Dec 2008 09:21:45 -0500
- To: "James Fuller" <james.fuller.2007@gmail.com>
- Cc: <public-xml-processing-model-comments@w3.org>
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". When I get further along in the implementation I will indeed take you up on that idea of sending more test cases. 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 :) -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:22:23 UTC