Re: [xsl] node kind of result tree

Subject: Re: [xsl] node kind of result tree
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 21 Jan 2013 18:07:38 -0500
At 2013-01-21 17:33 -0500, Michael Sokolov wrote:
On 1/21/2013 5:16 PM, David Carlisle wrote:

would produce a sequence of two documents, as I understand it


No. Each of the copy-of would copy a sequence of element nodes, the template will make an implicit (single) document node to hold the combined sequence of element nodes.

Ah, thanks David - I must have been confused. Somewhere I seemed to remember having to deal with the possibility that an XSL transformation could produce a sequence. Yes, here it is in the javadoc of JDOMResult:

 * A holder for an XSL Transformation result, generally a list of nodes
 * although it can be a JDOM Document also. As stated by the XSLT 1.0
 * specification, the result tree generated by an XSL transformation is not
 * required to be a well-formed XML document. The result tree may have "any
 * sequence of nodes as children that would be possible for an
 * element node".

Can you place that in proper perspective for us? Under what circumstances would we expect to get a sequence of nodes (not a document) from XSLT?

I do this *all* the time in my publishing environment for my training material.

You want to create a result tree with zero element nodes or multiple element nodes when you need to create external parsed general entities.

For example, my XSL-FO book incorporates over 200 external parsed general entities in order to form the content. I harvest information about formatting objects by running XSLT against the XSL-FO specification document, spitting out the 200 entities as fragments of spec content arranged, packaged and excerpted as required for my training material. Then in my training material I author entity references to pull in the required entity at the required time.

In this way, I am guaranteed that my training material matches the specification material for things like content models, parent nodes, mandatory attributes, optional attributes, etc.

In fact I started writing my XSL-FO book before I knew XSL-FO very well, because I was able to start with these 200 entities synthesized from the spec. I wrote the shell of my book to pull in the entities, and then I started reading my own book as to what I was able to harvest. As I learned more about the formatting objects, I filled in more content associated with each object. My book got thicker and thicker as I learned more. But, in effect, I learned the basics from my own book.

All of my books are written this way. For example, there are dozens of document types in OASIS UBL and my XSLT reads the spec and spits out content for my book. The first book where I used this technique is my XSLT book. The annexes in the books are summary reports that I never have to worry about making mistakes hand authoring as I'm generating the summaries from the specifications.

Oh ... and you don't have to produce elements. You can produce simple text in an output external parsed entity and pull that into an XML document. I've used this for titles of parts of the specification ... I just write out each title to an external parsed entity and reference it from my authored content. And if what you harvest happens to be the empty string, that's okay too! An empty file is a well-formed external parsed general entity.

This feature has been available since the release of XSLT 1.0 and it can be wielded very effectively.

I hope this is a useful example.

. . . . . . . . . . Ken

Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture:
Crane Softwrights Ltd.  
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Google+ profile:
Legal business disclaimers:

Current Thread