W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2009

[Bug 5332] [UPD] Parentheses around () or fn:error()

From: <bugzilla@wiggum.w3.org>
Date: Fri, 06 Feb 2009 18:05:42 +0000
To: public-qt-comments@w3.org
Message-Id: <E1LVV5C-0003JN-Es@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5332


zhen hua liu <zhen.liu@oracle.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zhen.liu@oracle.com




--- Comment #8 from zhen hua liu <zhen.liu@oracle.com>  2009-02-06 18:05:42 ---
This bug does not seemed to be resolved yet based on the latest XQUF spec.
>
>
>     From: w3c-xml-query-wg-request@w3.org [mailto:w3c-xml-query-wg-request@w3.org] On Behalf Of Zhen Liu
>     Sent: 05 February 2009 20:13
>     To: w3c-xml-query-wg@w3.org
>     Subject: issues of vacuous expression in XQUF
>
>     In the latest XQUF spec, vacuous expression is defined as
>     Definition: A vacuous expression is a simple expression that can only return an empty sequence or raise an error.]
>     I recall it is introduced because March 2008 version of XQuery scripting extension has
>     added vacuous expression concept and then XQUF started to adopt this concept.
>
>     My first question:
>     =====================
>      My understanding from the rest of XQUF spec that defines how vacuous expression is
>     determined is that the vacuous expression analysis is done statically. This means one can
>     figure this out without dynamic evaluation. If so, we shall fix the definition to reflect this. It is
>     not clear from the definition that vacuous expression is determined statically.
>
>     Furthermore, what type of static analysis is allowed here ?
>
>     For example, given the following expression:
>     if (fn:true()) then () else 3
>
>     If the static analysis is sophisticated, it can figure out this expression only returns empty sequence,
>     so it  is a vacuous expression.  But if one follows the current XQUF spec AS IS, this is not
>     vacuous expression. This appears to be quite inconsistent as the current XQUF can deduce that
>     if (cond) then () else ()
>     as vacuous expression, but why not
>     if (fn:true()) then () else 3
>
>      My second question regarding to function call:
>     ========================================
>     According to 2.5.6 Function call in XQUF, it states that a call to the built-in function fn:error()
>     is a vacuous expression. What about calling a function which always return empty sequence?
>     That function call shall be considered as vacuous expression, right ?
>
>     If so, then just as 'updating' keyword,
>      'vacuous' shall be used as a keyword to describe function as well
>     But this is not the case in the XQUF spec.
>
>     The other situation is that in many situations, a caller may invoke functions defined in other modules
>     whose query text may not be available to do static analysis, in such case,
>     how could one determine if a
>     function call is vacuous unless vacuous is a keyword to describe a function.
>
>     So it seems to me that introducing vacuous expression in XQUF appears to be unnecessary.
>     The latest XQuery scripting extension has dropped the vacuous expression category completely.
>     Shall we revert the XQUF back to the version which does not have vacuous expression
>     definition ?
>
>     The trigger that promotes me on this is that the latest XQUF conformance tests start to add
>     test cases that require static analysis of  vacuous expressions crossing typeswitch, conditional
>     expr, sequence expr etc.  While adding static analysis to support vacuous expression determination
>     is a  simple exercise, there appears to be some fundamental issues
>     regarding to vacuous expressions (described above)  that needs to be resolved.
>
>     Thanks
>
>     zhen
>


-- 
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 Friday, 6 February 2009 18:05:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:26 UTC