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
-Mike
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.
David
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: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers: http://www.CraneSoftwrights.com/legal