1660 2005-07-16 07:19:15 +0000 [FS] editorial: 4.7.3.2 Computed Attribute Constructors 2007-09-19 07:41:54 +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 4744 0 jmdyck 2005-07-16 07:19:15 +0000 4.7.3.2 Computed Attribute Constructors Norm / rule (2|3) "fs:item-sequence-to-untypedAtomic( ... )" This function takes a single argument (of type item*), but [[ Expr ]]_Expr could result in a sequence of comma-separated ExprSingles, which would then constitute multiple args. Put [[ Expr ]]_Expr in parentheses to ensure a single arg. DEv / rule (1|2) "fs:item-sequence-to-untypedAtomic(Expr)" Similar to previous. Put "Expr" in parentheses to ensure a single arg. DEv / rule (1|2) dynEnv |- fs:item-sequence-to-untypedAtomic(Expr) => Value The AttributeValue in the conclusion wants a SimpleValue, for which Value is too general. But we know that item-sequence-to-untypedAtomic will return an atomic value, so rename "Value" as "AtomicValue" (which satisfies the need for a SimpleValue). DEv / rule 1 / conclusion attribute expanded-QName of type xdt:untypedAtomic { Value } The EBNF for AttributeValue says that the thing after the "attribute" keyword is an AttributeName (i.e., QName), not an expanded-QName. (leftover from last year, comment #077) DEv / rule 2 "statEnv |- QName1 = xs:QName(Value1)" The xs:QName constructor function returns a value from the value space of xs:QName, which in the Formal Value syntax is denoted by 'expanded-QName', so change "QName1" to "expanded-QName". This then also runs afoul of the AttributeValue EBNF. So perhaps the EBNF should be changed, from "QName" to "expanded-QName". DEv / rule 2 / premise 3 "statEnv |- QName1 = xs:QName(Value1)" You don't need a static environment for such a judgment. DErr / para 1 "not a xs:QName. the xmlns namespace." Delete "the xmlns namespace." 9268 1 simeon 2006-04-16 23:35:01 +0000 Fixed as suggested. Replaced QName1 = xs:QName(Value1) by the syntactic construction of an QName using the fn:prefix-from-QName and fn:localname-from-QName functions. This is used similarly in the refactoring of the dynamic rules in 4.7.3.1 Computed Element Constructors. - Jerome 9551 2 jmdyck 2006-05-01 23:09:57 +0000 (In reply to comment #1) > Replaced QName1 = xs:QName(Value1) by the syntactic construction > of an QName using the fn:prefix-from-QName and fn:localname-from-QName > functions. This is used similarly in the refactoring of the > dynamic rules in 4.7.3.1 Computed Element Constructors. I think this approach might be a mistake. I'm inclined to think that in an AttributeValue or ElementValue, the name should be an expanded-QName, not a QName. Using QName assumes a) that its prefix is bound to the appropriate namespace name in the in-scope namespaces; and b) that that same binding exists everywhere in the inference process that the QName needs to be expanded. I don't think either assumption is true. 12250 3 jmdyck 2006-10-03 05:53:39 +0000 In the 2006-06 CR, this is not fixed: > > DEv / rule (1|2) > "fs:item-sequence-to-untypedAtomic(Expr)" > Similar to previous. > Put "Expr" in parentheses to ensure a single arg. Also, there's been no response to Comment #2. 12610 4 jmdyck 2006-10-26 02:23:22 +0000 Re the issue I raised in Comment #2, I've split it off (and generalized it) into Bug 3863. 16678 5 jmdyck 2007-09-19 01:23:48 +0000 The unresolved portion of this issue (i.e., the first part of Comment #3) has been entered as FS erratum E005. A fix has been committed to the source files for the next edition of the FS document. Consequently, I'm marking this issue resolved-FIXED, and CLOSED.