- From: Erik Bruchez <erik@bruchez.org>
- Date: Tue, 14 Oct 2003 14:42:54 -0700
- To: public-qt-comments@w3.org
> So let's all just implement the functions of XPath 1.0 (since we > need them for backwards-compatibility). Then, should we use the Perl > functions, or the Java functions, or the C/C++/C# functions, or the > SQL-functions or the EXSLT functions and/or... Remember that I am just talking about functions operating on strings here. But yes, of course, ideally one should look at all of those languages and libraries. There will be a lot of overlap between all those anyway. > The point is that we attempt to design a function library that > provides the minimal support necessary to provide interoperability > among implementation. If you add too many functions, you will not > get achieve that and you will add to the delay of the spec... Sure. String functions are usually quite easy to implement though, and I doubt that it would be a huge obstacle to building interoperable implementations to add a couple of string functions. > Note that there is nothing that forbids us to add more functions > later or encourages implementers to provide additional functions in > their implementation which then can be used to gather information > about their usefulness. This then can be used to determine future > extensions of the function library... But the usefulness of many functions can be already determined by looking at what's available in existing function libraries. Take XPath 1.0 for example. It has a starts-with() function, but no ends-with(). Maybe somebody used that argument back in 1998 / 1999 that if you added ends-with(), the spec would be delayed and that it would limit interoperability, and that ends-with() is after all not that useful a function anyway. But I think that even at the time (almost the prehistory of XML ;-) it was possible to foresee that such a function would be useful, and it would have been possible to build a decent string function library in 1.0 without too much hassle by just looking at what was already in the Java API, for example. All I am doing here is to try to avoid repeating the same mistake and then to be stuck for another 4 years with a lacking function library. That's for the theory. Note that I find the current selection of functions in XPath 2.0 quite good already, but some holes are questionable, which was the point of my initial comment. -Erik
Received on Tuesday, 14 October 2003 17:42:59 UTC