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 6733 - [XQX] XQueryX for leading "/"
Summary: [XQX] XQueryX for leading "/"
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQueryX 1.0 (show other bugs)
Version: Recommendation
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: 2009-03-24 19:00 UTC by Andrew Eisenberg
Modified: 2010-01-07 23:14 UTC (History)
1 user (show)

See Also:


Attachments

Description Andrew Eisenberg 2009-03-24 19:00:04 UTC
In Bug #5727, we agreed to add the following text to constraint "leading-lone-slash" in Appendix A.1.2:

"Therefore to reduce the need for lookahead, if the token immediately following
a slash can form the start of a RelativePathExpr, then the slash must be the
beginning of a PathExpr, not the entirety of it."


Let's consider the following query:

(/) * 5


A user might write this as:

<?xml version="1.0"?>
<xqx:module xmlns:xqx="http://www.w3.org/2005/XQueryX"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://www.w3.org/2005/XQueryX
                                http://www.w3.org/2005/XQueryX/xqueryx.xsd">
  <xqx:mainModule>
    <xqx:queryBody>
      <xqx:multiplyOp>
        <xqx:firstOperand>
          <xqx:pathExpr>
            <xqx:rootExpr/>
          </xqx:pathExpr>
        </xqx:firstOperand>
        <xqx:secondOperand>
          <xqx:integerConstantExpr>
            <xqx:value>5</xqx:value>
          </xqx:integerConstantExpr>
        </xqx:secondOperand>
      </xqx:multiplyOp>
    </xqx:queryBody>
  </xqx:mainModule>
</xqx:module>


Our stylesheet translates this into (/*5), which is invalid.

We could change the stylesheet so that (/) * 5 is generated.

If we make no change, then the user would have to wrap the xqx:pathExpr in an xqx:sequenceExpr element.
Comment 1 Jim Melton 2009-04-02 20:01:57 UTC
The problem with a bug like this one is that it takes us down (however slightly) the slippery slope of trying to make valid XQuery expressions out of nearly arbitrary XQueryX syntax. 

As one participant told me, "If users can write arbitrary xqueryx, and every such xqueryx needs to translate into correct xquery, i bet i could hand you dozens of other bugs...it means there are valid XQueryX documents (by the schema) that the stylesheet will turn into not-correct XQuery, but that does not mean it's broken."

Without prejudice, I'm RESOLVING this bug as WONTFIX, but am willing to hear stronger arguments either that this case is sufficiently unique to justify special treatment, or that this is one of a set of cases that are sufficiently unique (and important) to justify special treatment. 

If you accept this resolution, please mark the bug CLOSED. 
Comment 2 Jim Melton 2009-04-30 23:59:40 UTC
Upon further consideration, the Working Group decided that it would be worth accommodating this common case and directed me to pose a solution.  Because we believe (I think) that the only case where this is needed is when the source XQueryX (.xqx) document contains the sequence:
          <xqx:pathExpr>
            <xqx:rootExpr/>
          </xqx:pathExpr>
I propose that the solution be to modify the template for xqx:rootExpr to become:
  <xsl:template match="xqx:rootExpr">
    <xsl:if test="parent::xqx:pathExpr">
      <xsl:text>( </xsl:text>
    </xsl:if>
    <xsl:value-of select="$SLASH"/>
    <xsl:if test="parent::xqx:pathExpr">
      <xsl:text> )</xsl:text>
    </xsl:if>
  </xsl:template>

I'm leaving the bug RESOLVED, but changing the resolution to FIXED.  If you agree with this solution, please mark it CLOSED. 
Comment 3 Michael Kay 2009-05-01 06:57:10 UTC
Two observations about this solution:

(a) it will insert the parentheses around any root expression whose parent is a path expression, whether or not the root expression is the only child of the path expression. I don't know if this cases arises or if it matters.

(b) an arguably more elegant way of coding the solution would be:

  <xsl:template match="xqx:rootExpr">
    <xsl:value-of select="$SLASH"/>
  </xsl:template>

  <xsl:template match="xqx:pathExpr/xqx:rootExpr">
    <xsl:text>( </xsl:text>
    <xsl:value-of select="$SLASH"/>
    <xsl:text> )</xsl:text>
  </xsl:template>
Comment 4 Jim Melton 2009-05-01 21:09:14 UTC
Mike, I'm sold.  I've made the changes you suggested.  Thanks!
Comment 5 Andrew Eisenberg 2009-11-25 17:42:04 UTC
I believe that more work is needed on this. Test case Steps-leading-lone-slash-10 contains the query:

$var[/*]

The XQueryX that I generate is:

    <xqx:queryBody>
      <xqx:pathExpr>
        <xqx:stepExpr>
          <xqx:filterExpr>
            <xqx:varRef>
              <xqx:name>var</xqx:name>
            </xqx:varRef>
          </xqx:filterExpr>
          <xqx:predicates>
            <xqx:pathExpr>
              <xqx:rootExpr/>
              <xqx:stepExpr>
                <xqx:xpathAxis>child</xqx:xpathAxis>
                <xqx:Wildcard/>
              </xqx:stepExpr>
            </xqx:pathExpr>
          </xqx:predicates>
        </xqx:stepExpr>
      </xqx:pathExpr>
    </xqx:queryBody>

This transforms into a query that does not parse:

$var[( / )child::*]


Comment 6 Jim Melton 2010-01-07 23:13:46 UTC
Good catch!

I've updated the XQueryX stylesheet to account for the case where a rootExpr is immediately followed by a stepExpr.  In the case where it is, the rootExpr is transformed to a slash without surrounding parentheses.  Where it is not immediately followed by a stepExpr, the surrounding parens are generated. 

I've marked the bug RESOLVED/FIXED.  As you have agreed with the resolution in separate email, I'm also marking it CLOSED.