xsl-list
[Top] [All Lists]

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

2014-12-18 12:51:13
The script 
https://github.com/dita-community/dita-utilities/blob/master/src/xslt/map-t
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.

Cheers,

Eliot
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com




On 12/18/14, 12:36 PM, "Graydon graydon(_at_)marost(_dot_)ca"
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:

On Thu, Dec 18, 2014 at 05:32:06PM -0000, Jason Davis 
nosaj3(_at_)gmail(_dot_)com
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


--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--

<Prev in Thread] Current Thread [Next in Thread>