1677 2005-07-17 07:42:14 +0000 [FS] editorial: 4.12.2 Typeswitch 2007-02-25 23:16:37 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Last Call drafts All All CLOSED FIXED P2 minor --- 1 jmdyck simeon public-qt-comments oldest_to_newest 4763 0 jmdyck 2005-07-17 07:42:14 +0000 4.12.2 Typeswitch Introduction "This variable is optional in [XPath/XQuery] but mandatory in the [XPath/XQuery] Core." Not according to the Core Grammar. "One of the reasons for having this variable is that it is assigned a specific type for the corresponding branch." Is this a reason for requiring the variables in the Core, or a reason for someone to use them in XQuery? If the former, I don't find it convincing. If the latter, reword and move it before the preceding sentence, so it isn't mistaken for the former. Core Grammar I guess you should make the $VarNames mandatory, if that's what you want. Norm "The following normalization rule adds a newly created variable that does not appear in the rest of the query. Note that $fs:new is a newly generated variable that must not conflict with any variables already in scope and that is not used in any of the sub-expressions." These two sentences say roughly the same thing. Merge. Also, s/rule/rules/, as it applies to rules 1 and 3. Notation 2 "The following auxiliary grammar production is used to identify branches of the typeswitch." I don't think "identify" is the correct verb. CaseRules is a right-recursive restructuring of the clauses of a TypeswitchExpr. "[79 (Formal)] CaseRules ::= ..." Why not use this in the actual Core grammar? (leftover from last year, comment #111) I don't think 'CaseRules' is a very good name, especially in a document where "rule" already means something quite different. How about 'CaseClauses'? "statEnv |- Type1 case CaseRules : Type" No, this judgment is not applied to CaseRules, but only to individual clauses. So, you could declare it twice, once for CaseClause and once for a default clause. (It would help if Core had a DefaultCaseClause.) is used in the static of" Insert "semantics" after "static"? "the given case rule yields the type Type" s/rule/clause/ "the given case rules yields the value Value2." s/rules/clauses/ s/yields/yield/ DEv "the remaining case rules are evaluated order" s/rules/clauses/ Insert "in" before "order". DEv / rule 3 / conclusion case SequenceType VarRef # -> # case VarRef as SequenceType leftover comment #112 DErr "evaluation of any case rule" s/rule/clause/ 9167 1 simeon 2006-04-11 22:45:53 +0000 Fixed as suggested. - Jerome 12265 2 jmdyck 2006-10-04 05:26:59 +0000 "The following normalization rules add newly created variables that must not conflict with any variables already in scope and that are not used in any of the sub-expressions." This is still fairly clunky. How about deleting: "and that are not used in any of the sub-expressions." It doesn't seem like an important point. You didn't answer the question: > Why not use this in the actual Core grammar? I.e., what's the point of the current Core productions? Specifically, replace [33 (Core)] TypeswitchExpr ::= ... with [33 (Core)] TypeswitchExpr ::= "typeswitch" "(" Expr ")" CaseClauses [?? (Core)] CaseClauses ::= (CaseClause CaseClauses) | DefaultCaseClause [?? (Core)] DefaultCaseClause ::= "default" "$" VarName "return" ExprSingle and drop [68,69,70 (Formal)]. (And change the "Formal" symbols appropriately where they occur in rules.) And you missed: > "the remaining case rules are evaluated" > s/rules/clauses/ 13598 3 simeon 2007-01-16 17:58:50 +0000 Fixed the text, but left the grammar unchanged, defined at the XQuery 1.0 level. - Jerome