- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 01 Jan 2008 12:34:06 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5333 Summary: [UPD] Reference to clause 1e for enclosed expressions unclear Product: XPath / XQuery / XSLFO / XSLT Version: Last Call drafts Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Update Facility AssignedTo: andrew.eisenberg@us.ibm.com ReportedBy: mike@saxonica.com QAContact: public-qt-comments@w3.org The rules for the transform expression say (in 1a): "The source expression is evaluated as though it were an enclosed expression in an element constructor (see Rule 1e in Section 3.7.1.3 ContentXQ.)" However, Rule 1e only describes part of the processing of an enclosed expression in an element constructor. It's not clear whether the other parts of the processing are being expressly excluded. If the expression really were an enclosed expression in an element constructor, then a document node would be replaced by its children (rule 2) and adjacent text nodes would be merged (rule 3), and this would make a significant difference to the outcome. If it's only rule 1.e that is to be applied, then it's unreasonable to expect the reader to infer this from a parenthetical cross-reference. Also, 3.7.1.3 clause 1.e.ii.B refers to "the node constructed by this constructor", which makes no sense in this context. The parent property of a copied node should be set to null (or whatever euphemism for null we are using this week). It may be clearer to avoid the cross-reference to the XQuery 1.0 specification and extract the rules that actually apply in this case. ("as though" in specifications, like "may not", is a phrase that should always sound alarm bells). The same problem occurs in section 2.4.1 dealing with insert expressions. However, in this case I think it actually makes no difference to the final outcome whether rules 2 and 3 of the rules for enclosed expressions are applied or not.
Received on Tuesday, 1 January 2008 12:34:11 UTC