This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The following functions are missing from the F&O document. Most of them are defined as operators, however operators are not really functions. Operators cannot be manipulated as functions (passed as parameters, returned as results, partially-applied, ..., etc). Due to this problem we end up with well-defined and useful HOF facility that is not applicable to many important functions, only because they are not defined as functions in the document. Thus, for a higher order function that has as arguments: 1. a function of two arguments 2. item1 3. item2 The following functions can never be passed as the value of the first argument: eq(), ne(), =(), !=(), lt(), gt(), ge(), le(), or(), and(), ..., etc. Isn't it strange that we have defined these for dates and durations but lack the appropriate function definitions for arguments of all other types? A small part of the listed missing functions are new in the sense that they are not defined even as operators, but are still important and often included in other languages. Here is the more or less complete list of missing functions: (Polymorphic) comparison functions: eq() -- the "eq" operator ne() -- the "ne" operator lt() -- the "lt" operator gt() -- the "gt" operator le() -- the "le" operator ge() -- the "ge" operator Boolean functions: or() -- the "or" operator and() -- the "and" operator xor() -- new, logical xor implies() -- new, logical implication. Set functions: union() -- the "|" operator intersection() -- the "intersect" operator difference() -- the "except" operator symmetric-difference() -- new, set symmetric difference is-subset-of() -- new, set inclusion. is-true-subset-of() -- new, true set inclusion. is-member-of() -- new, membership of an item to a set. set-product() -- new, Carthesian product. Functions on functions: apply() -- the function application operator "()" Functions on sequences: concat-sequence() -- the "," operator item-at() -- the "[]" operator filter() -- the "[]" operator Functions on nodes: is-same-node() -- the "is" operator document-ordered() -- the "<<" and the ">>" operators Proposed action: Either define the functions listed above, or specify that the operators that are already defined in the document are functions in full right and can be manipulated as such; then define only the functions that are marked "new" in the above list.
Somehow missed the following: Polymorphic arithmetic functions: add() -- the "+" operator. subtract() -- the "-" operator. multiply() -- the "*" operator. divide() -- the "div" operator. Integer functions: integer-divide() -- the "idiv" operator. mod() -- the "mod" operator.
Thanks for your bug report - this is a personal response. I agree that it's important to make XQuery and XPath 2.0 operators available as functions, but I don't think these should necessarily be in the specifications. 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. It is my intention to design such a module when XQuery 1.1 and XSLT 2.1 become nearer completion, should no one step up to do so before me. A few comments on your list: set-product() - How would you represent the resulting sequence of pairs? apply() - How would you represent the list of argument values? filter() - This already exists in F&O 1.1
(In reply to comment #2) > Thanks for your bug report - this is a personal response. > I agree that it's important to make XQuery and XPath 2.0 operators available as > functions, but I don't think these should necessarily be in the specifications. The missing functions are among the *most important* XPath functions. They represent a significant hole in the current document. 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). > 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. 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". > It is my intention to design such a module when XQuery > 1.1 and XSLT 2.1 become nearer completion, should no one step up to do so > before me. With all due respect, it is the task of the WG to create consistent and complete documents that do not immediately need to be patched. Dimitre Novatchev.
(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.
> > 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 } The criterion whether something should be in the spec is not if it is not trivial to define. The criterion is how *important* that thing is. Never leave fundamental concepts out of the spec. > > 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. This statement is false. It is not "syntactic sugar" that HOF -- one of the most important features of XPath -- is not applicable to the most fundamental functions of the language. It should be obvious that defining a function in the spec does not require any changes in the syntax of the language. Dimitre Novatchev.
We might be willing to entertain a well-defined "set" data type, and/or set operations, for a future version of XPath beyond 2.1, as an enhancement request, with use-cases. The Working Groups are not willing to entertain making the operators available as functions.
(In reply to comment #6) > We might be willing to entertain a well-defined "set" data type, > and/or set operations, for a future version of XPath beyond 2.1, > as an enhancement request, with use-cases. > The Working Groups are not willing to entertain making the operators > available as functions. (personal) I am not satisfied with the decision. This leaves the new, HOF feature limited and not too useful. Thus there are significant gaps in the document, while at the same time there are proposals for work on relatively minor, not so significant functions. What do you think you are really doing? Designing math:pi() while not having or() and and() ? I have never had any hopes for an immediate positive reaction, but now at least you are aware what big problems this document has.
(In reply to comment #7) > > The Working Groups are not willing to entertain making the operators > > available as functions. (personal) People, forget about the word "operators". The fact is that we don't have very important functions such as or() and and(). Please, define them. Is this so difficult to understand? You have enormous holes in this document, defining multitude of other, less important functions only makes these holes more visible and ugly.