This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2289 - [xqueryx] base uri (and other aspects of the initial context)
Summary: [xqueryx] base uri (and other aspects of the initial context)
Status: CLOSED WONTFIX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQueryX 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Jim Melton
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-22 16:44 UTC by David Carlisle
Modified: 2005-09-29 11:56 UTC (History)
0 users

See Also:


Attachments

Description David Carlisle 2005-09-22 16:44:17 UTC
The XQueryX specification needs to define parts of the execution environment
that are not determined by the stylesheet translation to XQuery.

For example what is the meaning of:

<xqx:functionCallExpr>
    <xqx:functionName>doc</xqx:functionName>
    <xqx:arguments>
      <xqx:stringConstantExpr>
      <xqx:value>bib.xml</xqx:value>
     </xqx:stringConstantExpr>
    </xqx:arguments>
</xqx:functionCallExpr>

The semanics are defined by its translation by the stylesheet, to
doc("bib.xml")
but the meaning of that expression depends on the base URI in the initial
context in which this XQuery is evaluated, and that is currently undefined.

XQueryX should specify some constraints that say that the evaluation of the
XQueryX should be equivalent to execution of the generated XQuery with a static
context that is derived from that of the XQuery document (for example it has the
same base URI)
Comment 1 Jim Melton 2005-09-29 09:36:09 UTC
The Working Group discussed this comment at length.  Once we understood the
relationships between the XML syntax and the human-readable syntax for XQuery,
we recalled that it has always been our intent for the two syntaxes to have
equivalent semantics.  One important consequence of this is that the XQuery
static context to which you refer is exactly the same static context that an
XQueryX engine would use.  That is, the fact that a different syntax is used
does not mean that the evaluation/execution engine behaves any differently
(other than the nature of the parser, of course). 

Therefore, we conclude that no change to the XQueryX document is needed or
justifiable. 

Please let us know if you agree with this resolution of your issue, by adding a
comment to the issue record and changing the Status of the issue to Closed. Or,
if you do not agree with this resolution, please add a comment explaining why.
If you wish to appeal the WG's decision to the Director, then also change the
Status of the record to Reopened. If you wish to record your dissent, but do not
wish to appeal the decision to the Director, then change the Status of the
record to Closed. If we do not hear from you in the next two weeks, we will
assume you agree with the WG decision.
Comment 2 David Carlisle 2005-09-29 11:14:47 UTC
  The Working Group discussed this comment at length.  Once we understood the
  relationships between the XML syntax and the human-readable syntax for XQuery,
  we recalled that it has always been our intent for the two syntaxes to have
  equivalent semantics. 

If it takes the WG considerable time to remind themselves of this conclusion,
how is anyone else supposed to _ever_ come to this conclusion?

What is the objection to adding this paragraph

> one important consequence of this is that the XQuery
> static context to which you refer is exactly the same static context that an
> XQueryX engine would use.  

to the xqueryx spec?

My current XqueryX evaluator works by 
a) running the stylesheet from the spec, writing the Xquery to a temporary file
b) executing the Xquery in an Xquery engine.

This works most of the time (including I think all of the current test suite)
but fails on (the xqueryx equivalent of) the Query

base-uri(<a/>)

which the above paragraph makes clear should return the URI of the XQueryX
document, but my system currently returns the URI of the temporary file.

This is an essentially editorial matter, just requesting that the WG's intention
is stated in the document, as it is certainly not at all easy to come to that
conclusion currently. 

David
Comment 3 Jim Melton 2005-09-29 11:44:39 UTC
Your point is well taken.  We will add a (non-normative) note giving the reader
of the XQueryX spec notice that the static environment for XQueryX is the same
as for XQuery. 

I am leaving the resolution as it is, even though we are making this change,
because I prefer not to re-open the bug only to intantly close it.  However, if
you want it marked differently, please let me know offline and I'll do so. 

Please let us know if you agree with this resolution of your issue, by adding a
comment to the issue record and changing the Status of the issue to Closed. Or,
if you do not agree with this resolution, please add a comment explaining why.
If you wish to appeal the WG's decision to the Director, then also change the
Status of the record to Reopened. If you wish to record your dissent, but do not
wish to appeal the decision to the Director, then change the Status of the
record to Closed. If we do not hear from you in the next two weeks, we will
assume you agree with the WG decision.
Comment 4 David Carlisle 2005-09-29 11:56:21 UTC
Thanks for your final note confirming a note will be added to the spec, this is
an entirely satisfactory outcome, so I'm closing this (which means I've closed
all the xqx reports I had open, I hope I didn't eat up too much of your F2F time...)