W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2009

[Bug 7247] New: xquery full text grammar ambiguity?

From: <bugzilla@wiggum.w3.org>
Date: Sun, 09 Aug 2009 09:46:16 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-7247-523@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7247

           Summary: xquery full text grammar ambiguity?
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Full Text 1.0
        AssignedTo: jim.melton@acm.org
        ReportedBy: nikolay.ognyanov@gmail.com
         QAContact: public-qt-comments@w3.org


Consider the following expression:

element ftcontains {'whatever'}

Without full text it is clearly a computed element constructor. With full text
though it seems to also be FtContainsExpr by the rule

FTContainsExpr ::= RangeExpr ( "ftcontains" FTSelection FTIgnoreOption? )?

since 'element' is a valid relative path and hence - RangeExpr and
'{'whatever'}' is a valid FtWordsValue and hence - FTSelection. I am not able
to find in candidate recommendation from 07/09/2009 anything that would resolve
this ambiguity. Am I missing something? Similar constructs seem possible with
'ftand' and 'ftor' and with other computed constructors. Root cause of the
problem seems to be the "naked" curly bracket construct in FTWordsValue. There
used to be similar problems with "naked" blocks in Scripting which were
resolved by lead-in token "block".


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 9 August 2009 09:46:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:40 UTC