10074 2010-07-03 05:07:35 +0000 Missing operator definitions 2010-07-13 13:55:09 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.0 Working drafts PC Windows NT RESOLVED FIXED P2 normal --- 1 dnovatchev mike public-qt-comments oldest_to_newest 36555 0 dnovatchev 2010-07-03 05:07:35 +0000 In this WD I could not locate a definition for any of the following operators: op:boolean-or() -- as in "true() or false()" op:boolean-and() -- as in "true() and false()" op:location-step() -- this is the "/" character op: map-function() -- this is the "/"character followed by a function call op:apply-function() -- this is the "()" operator, which causes a function to be applied. Defining only some operators and not providing the definitions of other operators is confusing and as a negative consequence may imply to the reader that there is something special about the operators whose definitions are missing. 36558 1 mike 2010-07-03 11:42:42 +0000 You are quite right to point this out: I have always thought it was something of an oddity. For "and" and "or", I suspect the original justification was that these operators in XPath 1.0 had short-cut semantics, which means they were not pure functions of their arguments. However, the semantics changed over time and this argument is no longer valid. For the operators "/", "[]", and "()", the translation into functions produces higher-order functions which could not be represented in the 2.0/1.0 model. They can be represented now, so again this justification has probably disappeared. (But the function-call operator "()" is still a little challenging to describe this way since the number of arguments is unbounded.) The other side of the coin, however, is to question whether the mechanism of mapping operators to functions really serves any useful didactic purpose. It was quite handy in the early days before we decided which functions should have an operator syntax and which should only be available as function calls, but that's history. 36559 2 dnovatchev 2010-07-03 13:47:51 +0000 (In reply to comment #1) > The other side of the coin, however, is to question whether the mechanism of > mapping operators to functions really serves any useful didactic purpose. It > was quite handy in the early days before we decided which functions should have > an operator syntax and which should only be available as function calls, but > that's history. This has a much more important aspect than purely historical. Right now it isn't possible to pass an operator as a parameter or return it as result of a function. This significantly limits the scope of the HOFs in XPath. This issue was raised in bug 7350 among other issues. I still don't see any compelling reasons why operators shouldn't be part of the set of normal HOF functions where they do belong. Should I file a separate bug for this problem? Dimitre Novatchev. 36788 3 mike 2010-07-13 13:19:50 +0000 WG response: There are two questions here: (a) there is a lack of editorial logic in having underpinning functions for some operators but not others. This is essentially an editorial issue, and at the moment we don't feel we have the resources to make improvements in this area. (b) should the op: functions be exposed as a public interface? The WG feeling on this is that if we had intended them as a public interface, we would have designed them differently, and we do not currently see a compelling need for user-visible functions at this level, especially as it is easy for a user to add a function as a wrapper around the operator. 36791 4 dnovatchev 2010-07-13 13:55:09 +0000 (In reply to comment #3) > WG response: > There are two questions here: > (a) there is a lack of editorial logic in having underpinning functions for > some operators but not others. This is essentially an editorial issue, and at > the moment we don't feel we have the resources to make improvements in this > area. > (b) should the op: functions be exposed as a public interface? The WG feeling > on this is that if we had intended them as a public interface, we would have > designed them differently, and we do not currently see a compelling need for > user-visible functions at this level, especially as it is easy for a user to > add a function as a wrapper around the operator. (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.