W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2008

[Bug 5333] [UPD] Reference to clause 1e for enclosed expressions unclear

From: <bugzilla@wiggum.w3.org>
Date: Tue, 01 Jan 2008 12:34:06 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1J9gJq-0007Vg-IQ@wiggum.w3.org>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:49 GMT