[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 functions.) 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Want to process child and, Jason Davis nosaj3@x | Thread | Re: [xsl] Want to process child and, Eliot Kimber ekimber |
Re: [xsl] Want to process child and, Jason Davis nosaj3@x | Date | Re: [xsl] Want to process child and, Eliot Kimber ekimber |
Month |