Thanks very much for your comment.  As it happens, this same error was also
reported to me through a private communication from somebody else. 

The solution that I devised would result in an XML Schema element definition
that looks like the following.  The relevant change is to make the element
xpathAxis optional and remove the now-redundant elements nameText and Wildcard. 

  <xsd:element name="stepExpr">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
          <xsd:sequence>
            <xsd:element ref="xpathAxis" minOccurs="0"/>
            <xsd:choice>
              <xsd:element ref="kindTest"/>
              <xsd:element ref="nameTest"/>
              <xsd:element ref="Wildcard"/>
             </xsd:choice>
          </xsd:sequence>
          <xsd:element name="filterExpr">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:group ref="filterExpr"/>
              </xsd:sequence>
            </xsd:complexType>
          </xsd:element>
        </xsd:choice>
        <xsd:element name="predicates" type="exprList" minOccurs="0"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

I will propose this to the Working Group and, if approved, make the change as
indicated. 

Sorry -- my earlier response should have been explicit that it was the second
part of your comment that had been reported to me by somebody else and that I
propose to fix in the manner described.

The first part of your comment can be explained easily.  As your comment
indicated, relativePathExpr is a stepExpr optionally followed by / or // and
another stepExpr.  But the existing design of stepExpr in the XQueryX CR
document forced each stepExpr to start with an xpathAxis (e.g., child::,
equivalent to /).  And starting a relativePathExpr with an xpathAxis was just a
bit strange (to me, at least)!

However, with the changes I'm going to propose to resolve the second part of
your comment, stepExprs would no longer be required to start with an xpathAxis,
so the redundancy you cite would indeed now be redundant and could be
eliminated.  I will include this additional change in my proposal. 

(In reply to comment #1)
> Thanks very much for your comment.  As it happens, this same error was also
> reported to me through a private communication from somebody else. 
> 
> The solution that I devised would result in an XML Schema element definition
> that looks like the following.  The relevant change is to make the element
> xpathAxis optional and remove the now-redundant elements nameText and
> Wildcard. 

It's very inconsistent to have the axis specifier optional in this position.
omitting the axis here is the abbreviated xpath syntax for child:: and every
other part of the abbreviated xpath syntax (@, and //) is not reflected in
Xqueryx, but the expanded form is used instead. Why not here?


In your later reply you made two comments that I don't understand at all, sorry.

> e.g., child::, equivalent to /). 

whether the steps are separated by / or // has no effect on the axis specifier:
in both cases it is either given explictly or defaults to child::

> And starting a relativePathExpr with an xpathAxis was just a
> bit strange (to me, at least)!

Every relativepathexpr surely has to begin with an axis specifier (defaulted to
child:: if not explict) it is the axis that gives the "relation" of the relative
path. (well filter expressions are technachily also relative xpath but they 
are catered for in the xqueryx stepExpr with the filterexpr clause which doesn't
require an axis specifier,which is in agreement with the xquery grammar, there
is no need to have any special argExpr clause at the level of pathexpr

Also it wasn't clear to me whether you meant that you were agreeing to dropping
the argExpr clause from pathExpr.

David (slightly confused:-)

My apologies for leaving you confused. 

Upon further reflection (and additional discussions outside of the Bugzilla
context), I have concluded that your arguments are persuasive. 

In a previous response to this bug, I said that "starting a relativePathExpr
with an xpathAxis was just a bit strange".  Having considered your arguments at
greater length, I agree with you that making the initial xpathAxis optional in a
stepExpr leads to an inconsistency in the XQuery text that results from
transforming XQueryX using the XQueryX stylesheet.  I will now propose that the
leading xpathAxis be mandatory in stepExpr.  This will require a corresponding
change to Example 4. 

The revised solution that I intend to propose to the Working Groups will look
something like this: 

  <xsd:element name="stepExpr">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
          <xsd:sequence>
            <xsd:element ref="xpathAxis"/>
            <xsd:choice>
              <xsd:element ref="kindTest"/>
              <xsd:element ref="nameTest"/>
              <xsd:element ref="Wildcard"/>
             </xsd:choice>
          </xsd:sequence>
          <xsd:element name="filterExpr">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:group ref="filterExpr"/>
              </xsd:sequence>
            </xsd:complexType>
          </xsd:element>
        </xsd:choice>
        <xsd:element name="predicates" type="exprList" minOccurs="0"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:complexType name="pathExpr">
    <xsd:complexContent>
      <xsd:extension base="expr">
        <xsd:sequence>
          <xsd:element ref="stepExpr" maxOccurs="unbounded"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>

  <xsd:element name="pathExpr" type="pathExpr" substitutionGroup="expr"/>

Your additional thoughts on this sort of solution would be welcomed. 

Thanks for your feedback.

Clearly schema changes would require some changes to the stylesheet,
as for example the template for pathExpr currently looks for argExpr
children which would no longer there.

The notes below assume some educated (or more exactly, uneducated)
guesses about the changes you had in mind, as of course without the
stylesheet the meaning of the xqueryx that validates the new schema is
unspecified.

With that health warning over, I don't see how you intend to denote a
non-relative xpath such as /a/b as just allowing stepExpr in pathexpr
gives no place to record an initial rootExpr. Also the XQuery BNF for
pathExpr (ignoring the parts dealing with // which are not relevant
here) allows a choice (/ followed by 0-or-more steps) or (1-more-steps).

The position of rootExpr in the schema was already a little murky, see
for example bug #2525.

If I may make an explicit suggestion I would alter the CR schema as
follows


1)
Delete rootExpr as a top level element, so it can only appear in a
pathExpr

<!--
  <xsd:complexType name="rootExpr">
    <xsd:complexContent>
      <xsd:extension base="expr"/>
    </xsd:complexContent>
  </xsd:complexType>

  <xsd:element name="rootExpr" type="rootExpr" substitutionGroup="expr"/>
-->

2) define stepExpr as you suggest in your comment in this bug:

  <xsd:element name="stepExpr">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
          <xsd:sequence>
            <xsd:element ref="xpathAxis"/>
            <xsd:choice>
              <xsd:element ref="kindTest"/>
              <xsd:element ref="nameTest"/>
              <xsd:element ref="Wildcard"/>
             </xsd:choice>
          </xsd:sequence>
          <xsd:element name="filterExpr">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:group ref="filterExpr"/>
              </xsd:sequence>
            </xsd:complexType>
          </xsd:element>
        </xsd:choice>
        <xsd:element name="predicates" type="exprList" minOccurs="0"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

2) define pathExpr so it matches the Query BNF of (/ step* ) | (step+)

  <xsd:complexType name="pathExpr">
    <xsd:complexContent>
      <xsd:extension base="expr">
	<xsd:choice>
	  <xsd:sequence>
	    <xsd:element name="rootExpr" type="emptyContent"/>
	    <xsd:element ref="stepExpr" minOccurs="0" maxOccurs="unbounded"/>
	  </xsd:sequence>
	  <xsd:element ref="stepExpr" maxOccurs="unbounded"/>
	</xsd:choice>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  
  <xsd:element name="pathExpr" type="pathExpr" substitutionGroup="expr"/>


and alter the stylesheet to match:

3) define the template for pathExpr so that it processes rootExpr and
stepExpr rather than argExpr, predicates and stepExpr

  <xsl:template match="xqx:pathExpr">
    <xsl:apply-templates select="xqx:rootExpr|xqx:stepExpr"/>
  </xsl:template>



4) Define the template for stepExpr so that it only looks for other
stepExpr not any element before inserting a / (so you don't get a /
after a leading /, which (now) comes from processing rootExpr.

 <xsl:template match="xqx:stepExpr">
    <xsl:if test="preceding-sibling::xqx:stepExpr">
      <xsl:value-of select="$SLASH"/>
    </xsl:if>
    <xsl:apply-templates select="*"/>
  </xsl:template>


That's it...

Er I even tested this a bit.

Starting with the XqueryX below intended to represent the same thing
as the Xquery

(/,/a/b,a/b,ancestor::x[1],(ancestor::x)[1])

I claim the xqueryx is valid to the schema as modified above, and
produces

(/,
/child::a/child::b,
child::a/child::b,
ancestor::x[1],
(ancestor::x)[1])

if processed with the stylesheet as modified above, and that this is
probably the desired result:-)

<xqx:module xmlns:xqx="http://www.w3.org/2005/XQueryX">
  <xqx:mainModule>
    <xqx:queryBody>
      <xqx:sequenceExpr>
	<xqx:pathExpr>
	  <xqx:rootExpr/>
	</xqx:pathExpr>
	<xqx:pathExpr>
	  <xqx:rootExpr/>
	  <xqx:stepExpr>
	    <xqx:xpathAxis>child</xqx:xpathAxis>
	    <xqx:nameTest>a</xqx:nameTest>
	  </xqx:stepExpr>
	  <xqx:stepExpr>
	    <xqx:xpathAxis>child</xqx:xpathAxis>
	    <xqx:nameTest>b</xqx:nameTest>
	  </xqx:stepExpr>
	</xqx:pathExpr>
	<xqx:pathExpr>
	  <xqx:stepExpr>
	    <xqx:xpathAxis>child</xqx:xpathAxis>
	    <xqx:nameTest>a</xqx:nameTest>
	  </xqx:stepExpr>
	  <xqx:stepExpr>
	    <xqx:xpathAxis>child</xqx:xpathAxis>
	    <xqx:nameTest>b</xqx:nameTest>
	  </xqx:stepExpr>
	</xqx:pathExpr>
	<xqx:pathExpr>
	  <xqx:stepExpr>
	    <xqx:xpathAxis>ancestor</xqx:xpathAxis>
	    <xqx:nameTest>x</xqx:nameTest>
	    <xqx:predicates>
	      <xqx:integerConstantExpr>
		<xqx:value>1</xqx:value>
	      </xqx:integerConstantExpr>
	    </xqx:predicates>
	  </xqx:stepExpr>
	</xqx:pathExpr>
	<xqx:pathExpr>
	  <xqx:stepExpr>
	    <xqx:filterExpr>
	      <xqx:parenthesizedExpr>
		<xqx:pathExpr>
		  <xqx:stepExpr>
		    <xqx:xpathAxis>ancestor</xqx:xpathAxis>
		    <xqx:nameTest>x</xqx:nameTest>
		  </xqx:stepExpr>
		</xqx:pathExpr>
	      </xqx:parenthesizedExpr>
	    </xqx:filterExpr>
	    <xqx:predicates>
	      <xqx:integerConstantExpr>
		<xqx:value>1</xqx:value>
	      </xqx:integerConstantExpr>
	    </xqx:predicates>
	  </xqx:stepExpr>
	</xqx:pathExpr>
      </xqx:sequenceExpr>
    </xqx:queryBody>
  </xqx:mainModule>
</xqx:module>

Created attachment 428 [details]
XML Schema for XQueryX

This attachment contains the XML Schema that defines XQueryX, current with all Bugzilla bug solutions implemented as of 2006-06-13.

Created attachment 429 [details]
XSLT stylesheet for XQueryX

This attachment contains the XSLT Stylesheet that defines the semantics of XQueryX by transforming it to XQuery, current with all Bugzilla bug solutions implemented as of 2006-06-13.

Thanks for your ongoing interest in this issue and for your proposed solution.  The XML Query WG agreed with that solution and has approved its inclusion into the XQueryX specification.  Since we have adopted your solution, we assume that your concerns are satisfied.  I have marked this bug FIXED and request that you mark it CLOSED at your earliest convenience. 

In the interests of ensuring that the entire community has access to the most current version of the XQueryX schema and stylesheet, I am attaching both of those to this response. 

Thanks