- 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