[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Want to process child and decendent nodes the same way as parent node but can only process children

Subject: Re: [xsl] Want to process child and decendent nodes the same way as parent node but can only process children
From: "Graydon graydon@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 18 Dec 2014 18:36:03 -0000

On Thu, Dec 18, 2014 at 05:32:06PM -0000, Jason Davis nosaj3@xxxxxxxxx scripsit:
> Hi Graydon,
> Thanks for your tips. Could elaborate on this please? As I mentioned
> before, I'm an amateur when it comes to this stuff.
> From my perspective, it's not really a map merge. I'm just using the
> map as the source of truth for what a given reference resolves to.
> That just could be my vague interpretation of things. The style sheet
> I've put together almost accomplishes what I am attempting. The
> problem is I guess, as you say, I am attempting to "construct
> references of references to arbitrary depth." Is it really that
> difficult to extend what I have put together to process all the cross
> references in the way I desire?

It might be impossible if it really does have to be arbitrary depth,
because what you want to know isn't in this document, it's in that
document over there, and you can only readily "reach" through one level
of document indirection. (There's no easy way to nest document

Which is one of the initially annoying things about XML; it really is a
bunch of relationships between nodes, rather than neatly delimited text.
The good thing is that XSLT is a really good tree traversal language,
and the easy solution is going to be a tree traversal, so the effort of
seeing XML documents as trees pays off.

And, yeah, this problem really is a map merge; it's not a map merge for
content, but what you're doing can be thought of as traversing your
initial map, and everywhere you have a reference replacing it with the
thing referenced and continuing this with all the newly included content
until all the references are resolved throughout the whole constructed
tree.  That common pattern is the same pattern used in a DITA map merge.

Once you have the whole all-references-resolved document,
then you actually have the information you need -- all your references
are resolved -- to produce the output you want.

The easy way to move through the virtual all-references-resolved
document is to treat the references as "more tree over here" using the
document() or doc() functions and apply-templates.

Using apply-templates and selecting a document function effectively
changes the input document to the referenced document and away you go
processing that; because you've got that requirement for arbitrary
depth, this is the simple way to traverse the arbitrary tree constructed
by the references.

It might be easier as a development process to actually construct the
full merged map document (without initially worrying about DITA
validity!) and then start throwing stuff away.

The Open Toolkit used to call the thing it used to do map merges
topicmerge.xsl; that might be worth a look for an example of the
pattern.  (Unfortunately not an exceptionally simple example.)

-- Graydon

Current Thread