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 3760 - [FS] technical: injected calls to fs:item-sequence-to-node-sequence/-untypedAtomic
Summary: [FS] technical: injected calls to fs:item-sequence-to-node-sequence/-untypedA...
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Michael Dyck
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-21 09:47 UTC by Michael Dyck
Modified: 2007-10-02 02:09 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Dyck 2006-09-21 09:47:37 UTC
4.7.1 / Norm / rule 4
4.7.3.1 / Norm / rule (2|3)
fs:item-sequence-to-node-sequence(...)
    As far as I can tell, there's no justification for inserting a call
    to this function when normalizing direct and computed element
    constructors.  It's redundant, since the DEv semantics of
    CompElemConstructor (4.7.3.1 / DEv) call the function anyway.

    I suppose it's there because 4.7.3.1 / STA / rule (1|2) requires
    the content Expr of a Core CompElemConstructor to have a node-sequence
    type. But this seems needlessly constrained (and can lead to problems,
    see Bug 3758).  The STA rules could just as easily require the Expr
    to have an item-sequence type (i.e., the type that 7.1.5 / STA
    currently requires of the arg to fs:item-sequence-to-node-sequence).

4.7.1.1 / Norm / rule 5
4.7.3.2 / Norm / rule (2|3)
fs:item-sequence-to-untypedAtomic(...)
    Similarly, with 4.7.3.2 / STA / rule (1|2) and 7.1.7.
Comment 1 Jerome Simeon 2006-09-26 15:15:57 UTC
I think this is something that has been overlooked. the call to fs:item-sequence-to-node-sequence(...) should only be at one place.

I believe the right fix for this, consistent with the rest of the spec
would be to keep it in normalization, and remove it from the dynamic
evaluation rules.

- Jerome
Comment 2 Michael Dyck 2006-09-27 04:30:59 UTC
If you keep it in normalization, then it *won't* be in only one place, it'll be in 2 or 3 places. (And similarly with the attribute case.) I think you'd be better off removing it from normalization and keeping it in the dynamic semantics.

[I think it's a bad idea to take what is conceptually a part of the dynamic semantics of a construct (e.g., building the content-sequence of an element constructor) and say that it's not part of the dynamic semantics of the core construct, rather it's something that will have happened (because of a normalization injection) to an argument of the construct. It muddies the correspondence between the FS and XQuery specs, and makes it harder to convince oneself that they say the same thing (or to detect that in fact they don't). In short, it's an unnecessary and possibly detrimental complication.]
Comment 3 Jerome Simeon 2006-10-16 18:26:00 UTC
sigh... seems my previous post didn't get through.
so here it is again.

I meant to say one place as either normalization or dynamic evaluation. We could remove it from one or the others, and I think there could be arguments both ways. But as far as I know, fs:() functions are usually introduced through normalization so that might make it more consistent with other parts of the spec. also, all of the other constructors introduce those functions at normalization time so that is a much bigger change.

I recommend that we close that bug by removing the fs:item-sequence-to-node-sequence(...) call from either the normalization or the dynamic semantics. And leave the choice about which one of those should be removed to editorial discretion.

- Jerome
Comment 4 Michael Dyck 2006-10-17 04:47:46 UTC
(In reply to comment #3)
> 
> I meant to say one place as either normalization or dynamic evaluation.

Ah, I see what you mean. Yes, it should be in "one place" in at least that sense.

> I recommend that we close that bug by removing the
> fs:item-sequence-to-node-sequence(...) call from either the normalization or
> the dynamic semantics. And leave the choice about which one of those should be
> removed to editorial discretion.

Okay.
Comment 5 Jerome Simeon 2006-10-19 19:37:02 UTC
The XML Query and XSLT WGs have decided to adopt the proposed change to fix that bug, as specified in comment #3.
Best,
- Jerome, on Behalf of the WGs
Comment 6 Michael Dyck 2007-05-13 00:17:07 UTC
The analogous situation for attribute content (pointed out in Comment #0) has not been fixed in the Rec.
Comment 7 David Wilson 2007-09-14 12:59:45 UTC
I recommend that we close that bug by removing the
fs:item-sequence-to-node-sequence(...) call from either the normalization or
the dynamic semantics. And leave the choice about which one of those should be
removed to editorial discretion.

I agree on comment 3# 
www.shuttersdirect.nl
Comment 8 Michael Dyck 2007-10-02 02:07:20 UTC
The unresolved portion of this issue (Comment #6) has been resolved by the fix for FS erratum E011, which I have committed to the source files for the next edition of the FS document. Consequently, I'm marking this issue resolved-FIXED, and CLOSED.