2483 2005-11-08 17:03:32 +0000 type constraints too strict, might be wrong ? 2006-08-16 17:53:13 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Full Text 1.0 Working drafts Macintosh All CLOSED FIXED P2 normal --- 1 dflorescu holstege public-qt-comments oldest_to_newest 7094 0 dflorescu 2005-11-08 17:03:32 +0000 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. 8996 1 holstege 2006-03-31 22:45:01 +0000 We agreed to simplify the production for FTWords to (Literal | ("{" Expr "}") FTAnyallOption? A detailed review and proposal wrt other cases is at http://lists.w3.org/Archives/Member/member-query-fttf/2006Jan/0044.html 9899 2 jim.melton 2006-05-26 00:00:39 +0000 Thank you for your comment. The Task Force has resolved this bug by taking the action specified in http://www.w3.org/Bugs/Public/show_bug.cgi?id=2483#c1 We have marked this bug FIXED. If you agree with the resolution, please mark the bug CLOSED; if you do not agree, then please enter another comment on this bug. If you do not do either of those actions by 2006-06-08, we will mark it CLOSED under the presumption that you agree with the resolution.