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 3315 - [XqueryX] spurious "as" in typeswitch clause with no variable
Summary: [XqueryX] spurious "as" in typeswitch clause with no variable
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQueryX 1.0 (show other bugs)
Version: Candidate 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: 2006-06-05 22:49 UTC by David Carlisle
Modified: 2006-06-13 22:48 UTC (History)
0 users

See Also:


Attachments
XML Schema for XQueryX (40.14 KB, application/xml)
2006-06-13 17:59 UTC, Jim Melton
Details
XSLT stylesheet for XQueryX (38.97 KB, application/xml)
2006-06-13 18:00 UTC, Jim Melton
Details

Description David Carlisle 2006-06-05 22:49:24 UTC
The Schema for typeswitch case clause is

  <xsd:element name="typeswitchExprCaseClause">
    <xsd:complexType>
      <xsd:complexContent>
        <xsd:extension base="expr">
          <xsd:sequence>
            <xsd:element ref="variableBinding" minOccurs="0"/>
            <xsd:element ref="typeDeclaration"/>
            <xsd:element name="resultExpr" type="exprWrapper"/>

which means that there is always a "typeDeclaration" even if there is no variable binding.

The XSLT though has

 <xsl:template match="xqx:typeswitchExprCaseClause">
    <xsl:text> case </xsl:text>
    <xsl:apply-templates select="xqx:variableBinding"/>
    <xsl:apply-templates select="xqx:typeDeclaration"/>
    <xsl:text> return </xsl:text>
    <xsl:apply-templates select="xqx:resultExpr"/>
  </xsl:template>

and

<xsl:template match="xqx:typeDeclaration">
    <xsl:text> as </xsl:text>
    <xsl:apply-templates select="*"/>
  </xsl:template>


so typeDeclaration always gets processed and the text " as " is always generated.

so an XQuery Clause of
			case xs:integer return -1
if converted to XQueryX and back comes out as
			case as xs:integer return -1
which is a syntax error.

I think the correct fix is to change the schema to use sequenceType rather than typeDeclaration as the child of typeswitchExprCaseClause as that brings XQueryX back closer to the XQuery EBNF

[44]    CaseClause    ::=    "case" ("$" VarName "as")? SequenceType "return" ExprSingle 

An alternative (but not so nice, I think) would be to leave the schema as-is but add another template to the stylesheet matching
match="xqx:typeswitchExprCaseClause/xqx:typeDeclaration"
that does not put in the "as" if there is no variable binding child.
(the stylesheet will need some changes in either case to make sure tahtas is inserted if there is a variable binding and a type.).
A third possibility that wouldn't require a change to the stylesheet would be to make the schema allow a variable binding _or_ a sequence type but not both.
(the variable binding clause does itself allow a child sequence type).

It turns out that the XQuery Test suite (even in 0.9) had no tests for case clauses that do not bind a variable so this has gone undetected for quite a while.  Some additional tests by Frans Englich picked this up.

David
Comment 1 Jim Melton 2006-06-05 23:23:14 UTC
Thanks for your comment -- and thank goodness for the new tests that helped find this bug.  I agree with the bug report and prefer your first solution (which I gather you do, too).  I will propose that solution to the XML Query WG. 
Comment 2 Jim Melton 2006-06-06 00:31:49 UTC
Upon further analysis of the problem, which is very real, I am not so certain about your proposed solution.  Here's why:

First, the suggestion to use xqx:sequenceType instead of xqx:typeDeclaration sounds good, as it brings XQueryX into alignment with XQuery.  One (intended) artifact of that change would be that, in the stylesheet, xqx:typeDeclaration outputs the "as" and xqx:sequenceType does not. 

But the problem is that the "as" must be output whenever there is an xqx:variableBinding present in the xqx:typeswitchExprCaseClause.  That means that the stylesheet must be changed so that xqx:variableBinding emits the "as" when, and only when, it appears in an xqx:typeswitchExprCaseClause (specifically, not when it appears in an xqx:typeswitchExprDefaultClause). 

I have made a proposal to the XML Query WG to resolve this bug with one change to the schema and two changes to the stylesheet. 
Comment 3 David Carlisle 2006-06-06 08:56:42 UTC
(In reply to comment #2)

Yes as I say the stylesheet would need some changes to make sure as appeared
or didn't appear in the right places, whether or not the schema was changed.
It was getting a bit late last night to test/suggest specific fixes.

David
Comment 4 Jim Melton 2006-06-13 17:59:47 UTC
Created attachment 434 [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.
Comment 5 Jim Melton 2006-06-13 18:00:15 UTC
Created attachment 435 [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.
Comment 6 Jim Melton 2006-06-13 18:04:50 UTC
Thank you again for reporting this bug.  The XML Query WG has reviewed the report and has endorsed a solution making certain changes to both the XML Schema and the XSLT stylesheet for XQueryX. 

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 as responses to this bug. 

Please inspect the attached Schema and stylesheet, especially the element definition for "typeswitchExprCaseClause" and the templates for element "typeswitchExprCaseClause" and for element "xqx:variableBinding". 

We believe that these changes resolves this bug.  I have marked the bug as FIXED and request that you mark it CLOSED at your earliest opportunity.  If you disagree with the solution, please add a new comment explaining your reasons. 
Comment 7 David Carlisle 2006-06-13 22:48:07 UTC
seems fine, thanks