1861 2005-08-19 15:58:15 +0000 [Xquery] Text node constructors: parent property 2005-09-14 17:37:04 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 1.0 Last Call drafts PC Windows XP CLOSED FIXED P2 normal --- 1 mike chamberl public-qt-comments oldest_to_newest 5449 0 mike 2005-08-19 15:58:15 +0000 Section 3.7.3.4 says The parent property of the text node is the node constructed by the nearest containing element or document node constructor, either direct or computed, if such a constructor exists; otherwise parent is empty. This seems quite wrong. Consider document{ let $x := text{"fred"} return count($x/..) } The "nearest containing document constructor" is irrelevant here. This returns zero. As with other constructors, the new node initially has no parent; evaluating the document{} constructor makes a copy of the text node that does have a parent. Michael Kay 5631 1 chamberl 2005-08-31 23:52:04 +0000 Yes, you are right. In fact, this problem is rather widespread. On 31 Aug 2005 the working group decided to fix all the node constructors, both direct and computed, to specify that the parent property of the constructed node is empty. This affects the following sections: 3.7.1.1 Rule 5c (direct element constructors) 3.7.2 (direct PI and comment constructors) 3.7.3.1 Rule 4c (computed element constructors) 3.7.3.2 (computed attribute constructors) 3.7.3.4 (text node constructors) 3.7.3.5 (computed PI constructors) 3.7.3.6 (computed comment constructors) These changes have been implemented, and I have marked the bug report as fixed and closed. Please reopen the bug report if you have any further concerns. Regards, --Don Chamberlin 6144 2 chamberl 2005-09-14 17:37:04 +0000 In addition to the changes already enumerated, I have made the following changes with the approval of the Query Working Group. These changes cause the "base uri" property to be handled by element constructors consistently with the "parent" property. Section 3.7.1.3: delete rule 5-b-ii Section 3.7.3.1: delete rule 4-b-ii Don Chamberlin