This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
First, the new stuff in XSLT and XPath is fantastic. XSLT and XPath has become a much more functional programming language. However, there are some limitations, particularly with XPath, that are very troubling. Computer Scientist John Hughes, in his famous paper "Why Functional Programming Matters" argues that "modularity is the key to successful programming." If we accept that (I do) then we must say that XPath 3.0 has failed in terms of modularity. There is none. With XPath 3.0 you can write entire programs (and the neat thing is that the programs can be dropped into any language that hosts XPath, such as XSLT and XQuery and Java and Python and Perl). However, the program must be written as one monolithic beast. There is no ability to break up the program into separate reusable parts that can then be glued together. For example, one XPath program cannot reuse an XPath program in another file. I recommend this be remedied before XPath 3.0 goes to Recommendation status.
Are you proposing a new requirement for the next version of XPath? This is rather late in the process to suggest new requirements for XPath 3.0.
Also: please remember the purpose of XPath: <quote> XPath is designed to be embedded in a host language such as [XSL Transformations (XSLT) Version 3.0] or [XQuery 3.0: An XML Query Language]. </quote> Both XQuery and XPath are functional, modular languages. XPath was never intended to be modular, it's not clear to me that XPath is the right level for this. That's something that could be explored, but not in this version.
I strongly concur with comment #2. XPath was never intended to be a complete programming language, and the fact that it was intended to act as a sublanguage is clearly stated in the specification. It should not be judged against goals that never existed.
> Are you proposing a new requirement for the next version of XPath? Yes, definitely. The requirement is for modularity, the ability to create reusable parts that can be glued together. > XPath was never intended to be modular Why not? XPath is the ideal language for modularizing, as it so incredibly portable. Please see chapter 7 of "Pearls of XSLT and XPath 3.0 Design" [1] for an example of an XPath program. Although it is a powerful and useful program, it is monolithic and not modular due to the severe limitations of the current XPath design. > I strongly concur with comment #2. XPath was never > intended to be a complete programming language Whether it was an explicit requirement or not, whether it was done knowingly or unknowingly, XPath is now a programming language. I offer this as evidence: 1. XPath functions 2. Sequence of statements 3. Input and output So XPath is a programming language, but with poor modularity. Let's complete the job and make it a modular programming language. [1] http://www.xfront.com/Pearls-of-XSLT-and-XPath-3-0-Design.pdf
I agree with Roger. As it may sound surprising, XPath 3.0 is a complete programming language. It has: 1. Conditional constructs -- since XPath 2.0. 2. Iterative constructs -- since XPath 2.0. 3. Variable definition (since XPath 2.0) and the ability to define variables whose values are sequences -- in XPath 3.0. 4. Function items (anonymous function) definition. 5. Indirect recursion [1]. 6. Ability to parse input(XML documents via doc() and text files via unparsed-text()). 7. Ability to create new nodes -- parse-xml(). 8. Closures -- see Roger Costello's work. Roger Costello has been working systematically to define in pure XPath data structures (such as re-writing my implementation of a Binary Search Tree) and complete applications using these. It is sad that such powerful programming language still lacks a feature to import reusable sets of function definitions that are written in this language. Roger's use case is compelling and it comes at the right time to be considered for XPath 3.1. I fully support this use-case and recommend to the w3c-xsl-xquery working group to include XPath modularity support in XPath 3.1. Dimitre Novatchev [1] Recursion with anonymous (inline) functions in XPath 3.0, at: http://dnovatchev.wordpress.com/2012/10/15/recursion-with-anonymous-inline-functions-in-xpath-3-0-2/
You are asking us to change the purpose of XPath and to redesign the language to suit that purpose. This was not one of the requirements for XPath 1.0, XPath 2.0, or XPath 3.0, and I do not believe it makes sense to hold up XPath 3.0 to consider this feature.
(In reply to comment #5) > Roger's use case is compelling and it comes at the right time to be > considered for XPath 3.1. > > I fully support this use-case and recommend to the w3c-xsl-xquery working > group to include XPath modularity support in XPath 3.1. Considering this for XPath 3.1 is more appropriate than adding it as a requirement to XPath 3.0. If you want function libraries to XPath, though, why not just use XQuery?
If you completed this job and made XPath a functionally complete programming language, how would it differ from XQuery?
(In reply to comment #8) > If you completed this job and made XPath a functionally complete programming > language, how would it differ from XQuery? I believe that this language would be lighter and much simpler. It will eliminate the "portability problem" between XQuery and XSLT. Even only this fact will make it popular and preferred. XPath is not a competitor to either XQuery or XSLT -- it is a common subset of both. A XPath program is by definition a standalone program, an XQuery program and trivially makes an XSLT program. Any organization that uses both XSLT and XQuery would prefer the "write once" capability of XPath and this directly translates into significant money savings. To an organization that hasn't yet started using either XSLT or XQuery, XPath can be a good "starter" to either of these languages. Even before having made a decision which of XQuery/XSLT to use, they will know that all their XPath programs will be immediately running as part of either of these two languages.
(In reply to comment #6) > You are asking us to change the purpose of XPath and to redesign the > language to suit that purpose. > > This was not one of the requirements for XPath 1.0, XPath 2.0, or XPath 3.0, > and I do not believe it makes sense to hold up XPath 3.0 to consider this > feature. It often happens that a programming language is used not exactly as its authors imagined. The fact of such usage exists -- regardless of the wishes or beliefs of anyone. I think that it is useful to acknowledge the existence of facts sooner than later.
(In reply to comment #7) > (In reply to comment #5) > > > Roger's use case is compelling and it comes at the right time to be > > considered for XPath 3.1. > > > > I fully support this use-case and recommend to the w3c-xsl-xquery working > > group to include XPath modularity support in XPath 3.1. > > Considering this for XPath 3.1 is more appropriate than adding it as a > requirement to XPath 3.0. > > If you want function libraries to XPath, though, why not just use XQuery? Yes, I recommend that, based on Roger's use-case, support for modularity is included in XPath 3.1. And to answer the question on the last quoted line: There are some people that don't want to be bound XQuery or XSLT and prefer to have XPath programs that can be immediately executed either standalone, or as part of an XQuery program or (trivially included) as part of an XSLT program. Creating XPath programs eliminates the "portability problem" between XQuery and XSLT.
>I believe that this language would be lighter and much simpler. The paradox is that people love XPath for its lightness and simplicity, and those who love it the most want to add things to it that will make it heavier and more complex. Every feature that's in XQuery but not in XPath is a candidate for adding to XPath. Some such features (e.g. let expressions) have found their way in. If we add all such features, we have destroyed XPath. If we are to add only a few of the features, then we need a very strong view of the role of XPath and how it differs from the role of XQuery, to enable us to decide what goes in and what stays out. The view stated in the specification serves this purpose well: XPath is designed to provide XML navigation capability to augment other things that can be provided (better) by a host language. If we lose that focus, we lose XPath.
> XPath is designed to provide XML navigation capability > to augment other things that can be provided (better) > by a host language. If we lose that focus, we lose XPath. That focus was lost long ago. See comment 5 for many examples of capabilities existing in XPath today that have nothing to do with navigating through an XML tree. Despite this (in fact, because of this), XPath is prospering. I anticipate XPath to have an increasingly dominant role due to its portability -- write an XPath program once and reuse it in XSLT, XQuery, Java, Perl, Python. That's powerful!
(In reply to comment #11) > There are some people that don't want to be bound XQuery or XSLT and prefer > to have XPath programs that can be immediately executed either standalone, > or as part of an XQuery program or (trivially included) as part of an XSLT > program. > > Creating XPath programs eliminates the "portability problem" between XQuery > and XSLT. The best way to solve the portability problem is to allow XSLT to import and use XQuery libraries, and to allow XQuery to import and invoke XSLT stylesheets.
(In reply to comment #12) > >I believe that this language would be lighter and much simpler. > > The paradox is that people love XPath for its lightness and simplicity, and > those who love it the most want to add things to it that will make it > heavier and more complex. > > Every feature that's in XQuery but not in XPath is a candidate for adding to > XPath. Some such features (e.g. let expressions) have found their way in. If > we add all such features, we have destroyed XPath. If we are to add only a > few of the features, then we need a very strong view of the role of XPath > and how it differs from the role of XQuery, to enable us to decide what goes > in and what stays out. The view stated in the specification serves this > purpose well: XPath is designed to provide XML navigation capability to > augment other things that can be provided (better) by a host language. If we > lose that focus, we lose XPath. As with any new idea, some time is required in order to get accustomed and fully understand it, so let's not draw conclusions immediately. At present, if we have a set of useful functions written in pure XPath, and we want to use these both in XSLT and in XQuery, we must: 1. Save the XPath in one or more XSLT stylesheets. 2. Save the XPath as one or more XQuery module files. 3. In XSLT add an <xsl:import href="XPathFuncs.xsl"> directive. 4. In XQuery add: import module "some namespace" at "XPathFuncs.xq". As time goes we make some changes to the functions -- then we must not forget to do these changes both in XPathFuncs.xsl and in XPathFuncs.xq. This is both time consuming and, more importantly, error-prone. As result often we will have the xsl and xq files out of sync. Providing modularity in XPath completely eliminates this problem and makes both XSLT and XQuery more attractive to use. For function library developers writing the functions in pure XPath saves significant time and effort and completely eliminates the synchronization problems between an XSLT version and an XQuery version. The time saved could be used for doing more work and extending the coverage and quality of the library. All these benefits directly translate into cost savings and profit.
Roger, as things stand there are very few stand-alone XPath 2 implementations. Almost all XPath that's used outside XQuery or XSLT today is XPath 1. Everything from Web browsers, PHP, C libraries, C++ bindings, Perl, Java, Python, Scala, Scheme, and XML vocabularies like XForms, are primarily using XPath 1. This is for several reasons. The first is that there isn't a suitably-licensed XPath 2 (or later) implementation written in portable C (not C++, C). And no-one is getting very far in writing one because the language is too large and XPath 1is almost good enough. The second is that XPath 2 is large enough that Web browsers and Web server plugins are nervous of the memory footprint. If we do an XPath 3.1 I'm already thinking we should consider moving some core features out and make them optional. XPath needs to be the obvious first choice for pointing into XML-interchangeable trees, not a software engineering platform. If you want an extension to XPath that provides modules, it's called XQuery. Sure, it's neat to be able to define functions in XPath, although I think we were probably wrong to add it outside of XSLT and Query. Requiring XPath engines to support closures and joins is probably a death sentence for the language. On the other foot, I think we are all pleased when someone likes one of our specifications this much, and finds it cool and neat. Sometimes we forget that perspective, because we are so close to it. So I was pleased to see the comment, even if I happen not to agree that it's a good direction for XPath. But for sure we should discuss it in the XSLT and XQuery Working Groups.
(In reply to comment #15) > At present, if we have a set of useful functions written in pure XPath, and > we want to use these both in XSLT and in XQuery !!! SNIP !!! > Providing modularity in XPath completely eliminates this problem and makes > both XSLT and XQuery more attractive to use. I do not yet understand why it is important to you that this be done in pure XPath, rather than in an XQuery that uses only features of XPath + modules. If XSLT could import and use XQuery libraries, then XSLT and XQuery could share libraries in the same way you envision here.
(In reply to comment #16) > there are very few stand-alone XPath 2 > implementations. Almost all XPath that's used outside XQuery or XSLT today > is XPath 1. !!! SNIP !!! > XPath 2 is large enough that Web browsers and Web server plugins are nervous > of the memory footprint. I agree. I definitely think we need a standard profile of XPath 3.1 that is not much larger than XPath 1.0.
(In reply to comment #17) > (In reply to comment #15) > > > At present, if we have a set of useful functions written in pure XPath, and > > we want to use these both in XSLT and in XQuery > !!! SNIP !!! > > Providing modularity in XPath completely eliminates this problem and makes > > both XSLT and XQuery more attractive to use. > > I do not yet understand why it is important to you that this be done in pure > XPath, rather than in an XQuery that uses only features of XPath + modules. > > If XSLT could import and use XQuery libraries, then XSLT and XQuery could > share libraries in the same way you envision here. Yes, and although this may be technically possible, there are non-technical reasons why such a feature wouldn't be too-popular: A typical XQuery programmer: doesn't like too much XSLT ==> doesn't understand it too well ==> won't be able to make maximum use of imported XSLT A typical XSLT programmer: doesn't like too much XQuery ==> doesn't understand it too well ==> won't be able to make maximum use of imported XQuery Both, an XQuery programmer and an XSLT programmer: like XPath ==> understand XPath well ==> are able to make maximum use of imported XPath functions To put it in other words, one needs to learn another language to make full use of the benefits of importing code from that language. This requires time and investment, and there is no guarantee that many of us are that bi-lingual. This problem simply doesn't exist when importing XPath.
> The second is that > XPath 2 is large enough that Web browsers and Web server plugins are nervous > of the memory footprint. Actually Saxon CE implements not only XPath 2.0 but also XSLT 2.0 within a browser, as a set of JavaScript functions. In all five major browsers.
The Joint XSLT and XQuery Working Groups considered this request today. The consensus of the Working Groups is that this is (1) not the time in the W3C Process to be making breaking changes (at Candidate Recommendation) and (2) not the right direction for XPath.