- From: Michael Kay <mhk@mhk.me.uk>
- Date: Tue, 17 Feb 2004 16:09:53 -0000
- To: "'Mark Scardina'" <Mark.Scardina@oracle.com>, <public-qt-comments@w3.org>
This is a very interesting comment and we will obviously have to discuss it. However, I *think* that the weaknesses you point out are mainly editorial rather than technical. If I read you correctly, you're not quarelling with the basic processing model, whereby trees are constructed bottom up by building a sequence and then using this to form the children of a new element or document node; what you are saying is in large measure that the specification still contains relics of the older top-down processing model that we need to get rid of. Some specific responses: > Section 6.3 Applying Template Rules > In the section for <xsl:apply-templates> says that the > instruction takes as input a sequence of nodes from the > source tree (actually, it could be more than one source tree) > and produces as output a sequence of items. Later on it says > that the instruction writes to the result tree (?). Yes. This is lazy terminology. The Note in section 2.1 is effectively an apology for the loose use of the words "source tree" and "result tree" throughout the document, but we should remove the loose wording rather than apologizing for it. (My main concern in doing this has been how to keep the document understandable.) Anything that refers to instructions "writing to the result tree" is a hangover from the 1.0 spec and needs to be changed. > > Section 9: Variables and Parameters > In the Variable value definition, value is explicitly said to > be a sequence but later in section 9.4 in the same section it > also described under what conditions the value could be a > temporary tree. In this case I think both statements are true: a temporary tree is identified by a document node, and the document node is a singleton sequence containing one node. But the apparent contradiction needs to be explained better, and the terminology tightened up. > > Section 11.4.3 Generating Text with xsl:value-of > The description of <xsl:value-of> says that the generated > text is extracted from the source tree or by inserting value > of a variable, which is not exactly true. It is more precise > to say that the text is extracted from the sequence obtained > after evaluating the select expression or from the context item. Yes. > > Section 11.8.1 Shallow Copy > <xsl:copy> instruction is described as coping nodes from a > source tree to a result tree, which is incorrect. It is more > consistent with the document concepts to say that the > instruction copies the context item into the result sequence. Yes. > > I believe that the clarity of the document will only benefit if: > > - All of the language construct descriptions use only the sequence > paradigm (except for describing conversion from/to sequence). > This becomes possible if the result-tree creation is viewed > as a bottom-up process (not top-down as is in XSLT 1.0). > Source tree & result tree in Section 1.2 should not be used > in the context of individual instructions. Yes. > > - Sequence to tree conversion is performed explicitly by > <xsl:result-document> and implicitly as described in Section > 5.6.1 Constructing Complex Content. And also, of course, by instructions that invoke 5.6.1, such as xsl:element and xsl:copy. > A new > <xsl:result-document> attribute mode = { append, rewrite, & } > can be used to specify precisely how to construct and > serialize the output tree. I think this suggestion is orthogonal to the rest of the comment. I can see how it would be useful to say action=new|overwrite on xsl:result-document to control whether the system is allowed to overwrite an existing file. I'm not so comfortable with append, because (a) it's not clear what you get when you append one serialized XML document to another, and (b) the order of sub-documents in the output would be implementation-dependent. > > - Tree to sequence conversion is performed when a transformation > is initialized (initial context node) and by document function. I'm not sure I understand this comment. > > - The concept intermediate tree and output state are redundant and > should not be used. The only extra feature the intermediate > tree provides is the implicit document node as a root of the > tree. But this minor obstacle is easily solvable if XSLT 2.0 > has an <xsl:document> instruction. > The purpose of the "intermediate/final" distinction and output state is to limit the extent to which xsl:result-document can cause unpredictable side-effects. I'm not sure in my own mind whether the side-effect problems are really grave enough to justify this machinery. Michael Kay
Received on Tuesday, 17 February 2004 11:09:16 UTC