- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 08 Nov 2005 17:03:32 +0000
- To: public-qt-comments@w3.org
- Cc:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=2483 Summary: type constraints too strict, might be wrong ? Product: XPath / XQuery / XSLT Version: Working drafts Platform: Macintosh OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Full Text AssignedTo: sihem@research.att.com ReportedBy: dflorescu@mac.com QAContact: public-qt-comments@w3.org Several times in the document we use constraints on the type of the result of the evaluation of various XQuery expressions, i.e. they are requested to be of type xs:string or nodes of type xs:string. This seems to be inconsistent with the desired semantics, and would make errors cases that seem reasonable (e.g. cases of untyped data). An example of this occurence is in FTWords. ::= (Literal | VarRef | ContextItemExpr | FunctionCall | ("{" Expr "}")) FTAnyallOption? The right-hand side of the above production must evaluate to a sequence of string values or nodes of type "xs:string". The result is then atomized into a sequence of strings which is tokenized into a sequence of words and phrases. If the atomized sequence is not a subtype of "xs:string*", an error is raised: [err:XPTY0004]XP. We have to check all such constraints to see if this is the intended meaning.
Received on Tuesday, 8 November 2005 17:03:37 UTC