- 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