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.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.
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
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.]
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
(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.
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
The analogous situation for attribute content (pointed out in Comment #0) has not been fixed in the Rec.
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
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.