[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: "Eliot Kimber ekimber@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 18 Dec 2014 18:51:07 -0000

The script
o-map-transform/map-to-map-transform.xsl provides a sample of doing
general DITA map processing, including handling of nested map references.

I thought I had a general "resolve map" XSLT library but I can't find it
at the moment.

You can certainly use the OT's preprocessing to do map resolution, giving
you a fully-resolved map, with all the complicated DITA rules applied and
that's the right thing to do.


Eliot Kimber, Owner
Contrext, LLC

On 12/18/14, 12:36 PM, "Graydon graydon@xxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>On Thu, Dec 18, 2014 at 05:32:06PM -0000, Jason Davis nosaj3@xxxxxxxxx
>> 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