RE: ORA-XS-313-C: Comments about the XSLT 2.0 concepts.

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