This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1660 - [FS] editorial: 4.7.3.2 Computed Attribute Constructors
Summary: [FS] editorial: 4.7.3.2 Computed Attribute Constructors
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Last Call drafts
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Jerome Simeon
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-16 07:19 UTC by Michael Dyck
Modified: 2007-09-19 07:41 UTC (History)
0 users

See Also:


Attachments

Description Michael Dyck 2005-07-16 07:19:15 UTC
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."
Comment 1 Jerome Simeon 2006-04-16 23:35:01 UTC
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
Comment 2 Michael Dyck 2006-05-01 23:09:57 UTC
(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.
Comment 3 Michael Dyck 2006-10-03 05:53:39 UTC
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.
Comment 4 Michael Dyck 2006-10-26 02:23:22 UTC
Re the issue I raised in Comment #2, I've split it off (and generalized it) into Bug 3863.
Comment 5 Michael Dyck 2007-09-19 01:23:48 UTC
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.