W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2005

[Bug 2259] [xqueryx] xqx:constructorFunctionExpr

From: <bugzilla@wiggum.w3.org>
Date: Tue, 20 Sep 2005 11:49:59 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1EHgdL-0007Rn-Mv@wiggum.w3.org>

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





------- Additional Comments From jim.melton@acm.org  2005-09-20 11:49 -------
Thanks for the ongoing discussion; it is very helpful.  However, I have to
emphasize that there is absolutely no requirement or intent that the XQueryX
specification support any form of tranformation *from* XQuery to *to* XQueryX. 
I say this now because of Mike's remark in which he said "Is it intended that the
translation from XQuery to XQueryX...".  The answer to that is pretty close to
the SQL null value, because there is no intent that there *be* a translation
from XQuery to XQueryX, so there cannot be an answer about whether the static
context should come into play. 

Having said that, here is my personal (not terribly considered) thought: If the
transformation from XQueryX to XQuery, using the XQueryX stylesheet, transforms
both xqx:constructorFunctionExpr and xqx:functionCallExpr into identical XQuery
syntax, then what harm is there?  It would mean that XQueryX generators that
know enough about their environment to generate xqx:constructorFunctionExpr are
free to do so when appropriate, and everybody is free to generate
xqx:functionCallExpr in either situation. 

Why is that a problem?  Because some XQueryX generators don't have that context
and thus need to make a decision about whether or not to use
xqx:constructorFunctionExpr? The answer to such generators is that there is no
requirement that that use xqx:constructorFunctionExpr, but that they may if they
wish.
Received on Tuesday, 20 September 2005 11:50:11 UTC

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