This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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."
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
(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.
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.
Re the issue I raised in Comment #2, I've split it off (and generalized it) into Bug 3863.
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.