This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Some components, such as conditionals and viewports, are going to use XPath expressions. Are we going to define a (streamable) subset of XPath (1 or 2)? Are we going to require XPath 1 or 2? Are we going to allow pipelines to use either and accept some interoperability problems?
I see XPath (1.0 and 2.0) as being something complex enough that a pipeline implementation won't want to implement XPath but will rather use an available XPath implementation. In the Java world there is at least one good open source implementation of XPath 2.0 (Saxon), and as XPath 2.0 is so much more powerful and convenient that XPath 1.0, I don't see a reason not to use XPath 2.0. Is the situation different in other environements? Are there other reasons why people might want to use XPath 1.0 over XPath 2.0? Alex
The need for streamable subset of XPath is a real need, for XProc or for everything else. At this time, STXPath, which is based on XPath 2.0, is a good start, but it's may be out of the scope of just XProc WG http://stx.sourceforge.net/documents/spec-stx-20040701.html#stxpath-lang And there is XPath 2.0 (the biggest set of XPath language) and XPath 1.0 I think we should consider, letting the implementer choose a level of implementation for XPath, with a lowest level set to XPath 1.0 to be conformant; XPath 1.0 and STXPath, or something like, to be streamable conformant; XPath 1.0, STXPath and XPath 2.0 to be fully conformant
XPath 2, much as I like it, seems like a chainsaw where bread knife would be sufficient. Letting the implementation choose seems like the worst choice for interoperability.
Pipeline Authors Regarding the bread knife vs. chainsaw, I don't think that by providing XPath 2.0 to pipeline authors, we are giving them a "chainsaw", i.e something "cumbersome, where a bread knife would have been enough". To the an author XPath 2.0 looks very much like a super-set of XPath 1.0: it behaves like XPath 1.0 for simple expressions (especially with the backward compatibility mode) but can do much more when needed. So, just taking into account the perspective of the pipeline author, I see a strong case for XPath 2.0. Pipeline Implementers The perspective of pipeline implementers will be different. They are very likely to use an implementation of XPath. If an implementation of XPath 2.0 is available on their platform, then supporting XPath 2.0 vs. 1.0 does not make much difference. It does however make a difference if an implementation of XPath 2.0 is not available on their platform. In this case, it means that those implementers would have to start by writing their own implementation of XPath 2.0, and that would be an unnecessary burden on the implementer. In Conclusion The question is: what are the platforms where XPath 2.0 implementations are not available? Are implementers likely to want to write an implementation on those platforms? If the answer is yes to both questions, then I am in favor having multiple level of conformance. I don't think it is reasonable to force all the implementations to use just XPath 1.0 because XPath 2.0 is not available on some platforms. Alex
Per the 11 May 2006 meeting, we will not use a subset. Per the 18 May 2006 meeting, we will use XPath 1.0 (only) for the first draft. We'll request explicit feedback from users. We'll explicitly grant implementors the freedom to use an XPath 2.0 processor in backwards compatibility mode (as long as they detect and reject expressions that aren't valid 1.0 expressions).