- From: <bugzilla@jessica.w3.org>
- Date: Tue, 06 Jul 2010 16:39:26 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10089 --- Comment #4 from John Snelson <john.snelson@marklogic.com> 2010-07-06 16:39:26 --- (In reply to comment #3) > The missing functions are among the *most important* XPath functions. They > represent a significant hole in the current document. They are also among the most trivial functions to define outside the specs as well: function($a, $b) { $a lt $b } > On the other side, the spec define a lot of less important functions -- just > think how many date/date-time functions are there and how many people use date > functions on a daily basis vs. such important functions as and(), or(), > eq(), ... (any of the other missing functions). Some of us are keen to set a higher bar for adding functions to the specifications in future, for this and other reasons. > > Since these functions can easily be defined in XQuery or XSLT 2.0, I think > > instead they would be better off defined in a standard EXPath module that can > > be imported when needed. > > We don't need kludges, we need a clear and useful specification. The next step > after recognizing the hole in the spec is to fill it in, not to delay or > perpetuate it by avoiding responsibility and "delegating" the fix to another > party. I don't think having a clear distinction between language specification and function libraries is a kludge. Without a doubt the XQuery WG could spend a great deal of time on function libraries - but then there would be no time for more fundamental advances in the language itself. > EXPath's goal is to provide useful *extensions* to existing specifications. > This is not the case. In this case the specification needs to be fixed, not > "extended". Let's be clear - we're talking about syntactic sugar here, not a broken spec. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 6 July 2010 16:39:27 UTC