3760 2006-09-21 09:47:37 +0000 [FS] technical: injected calls to fs:item-sequence-to-node-sequence/-untypedAtomic 2007-10-02 02:09:16 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Candidate Recommendation All All CLOSED FIXED P2 normal --- 1 jmdyck jmdyck jmdyck public-qt-comments oldest_to_newest 11937 0 jmdyck 2006-09-21 09:47:37 +0000 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. 12049 1 simeon 2006-09-26 15:15:57 +0000 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 12069 2 jmdyck 2006-09-27 04:30:59 +0000 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.] 12499 3 simeon 2006-10-16 18:26:00 +0000 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 12505 4 jmdyck 2006-10-17 04:47:46 +0000 (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. 12549 5 simeon 2006-10-19 19:37:02 +0000 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 15080 6 jmdyck 2007-05-13 00:17:07 +0000 The analogous situation for attribute content (pointed out in Comment #0) has not been fixed in the Rec. 16589 7 dhwilson 2007-09-14 12:59:45 +0000 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 16957 8 jmdyck 2007-10-02 02:07:20 +0000 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.