I ended up doing
<xsl:variable name="is.chunk">
<xsl:call-template name="chunk">
<xsl:with-param name="node" select="."/>
</xsl:call-template>
</xsl:variable>
<xsl:for-each select=".//indexterm[$is.chunk = 0] |
(indexterm |*[not(child::section or child::preface or
child::book or child::chapter)]//indexterm)[$is.chunk = 1]">
</xsl:for-each>
And the generate files seems to be generated correctly...
:: Morten
-----Original Message-----
From: Olsen, Morten Engelhardt [mailto:[email protected]]
Sent: 20. mars 2013 16:26
To: Bob Stayton; [email protected]
Subject: RE: [docbook] Select chunk content from user.head.content template
No, using your xpath caused the header entry to be generated on the correct
chunk and at the highest section above the actual chunk.and on the topmost
chunk (book)
I see now that my attempt causes the entry on the correct chunk, an also on the
top-level chunk (matching to book I suppose)
My proposal is merely a monkey-bashing tweak of yours, and with my, I'm left
with how to not include everything on the book/top level?
:: Morten Engelhardt Olsen
________________________________________
From: Bob Stayton [[email protected]]
Sent: Wednesday, March 20, 2013 16:13
To: Olsen, Morten Engelhardt; [email protected]
Subject: Re: [docbook] Select chunk content from user.head.content template
Well, no, that logic seems backward to me. If the first child section is a
chunk, then $is.chunk = 1 is true, so .//indexterm is used and selects all
descendant indexterms, including those in the section chunks. Did that work
for you?
Bob Stayton
Sagehill Enterprises
[email protected]
--------------------------------------------------
From: "Olsen, Morten Engelhardt" <[email protected]>
Sent: Wednesday, March 20, 2013 1:53 AM
To: "Bob Stayton" <[email protected]>; <[email protected]>
Subject: RE: [docbook] Select chunk content from user.head.content template
> Thanks Bob, I never though of using the chunk template :P
>
> The for-each selector ended up as
>
> <xsl:for-each select=".//indexterm[$is.chunk= 1]
> |(indexterm|*[not(self::section or
> self::book)]//indexterm)[$is.chunk = 0]">
>
> same as yours, but excluding book nodes and reversed the is.chunk selector
> exclusions. Does this seem logical by you?
>
> :: Morten Engelhardt Olsen
> ________________________________________
> From: Bob Stayton [[email protected]]
> Sent: Tuesday, March 19, 2013 21:21
> To: Olsen, Morten Engelhardt; [email protected]
> Subject: Re: [docbook] Select chunk content from user.head.content
> template
>
> Hi Morten,
> There is a utility template named "chunk" that can be used to test if a
> given node is a chunk element. You could use it to check the first child
> section:
>
> <xsl:variable name="chunk.children">
> <xsl:call-template name="chunk">
> <xsl:with-param name="node" select="section[1]"/>
> </xsl:call-template>
> </xsl:variable>
>
> The $chunk.children will have a value of 1 if that section is a chunk, or
> 0
> otherwise. Then you can use that in the select statement:
>
> <xsl:for-each select=".//indexterm[$chunk.children = 0] |
> (indexterm
> |*[not(self::section)]//indexterm)[$chunk.children = 1]">
>
> The select statement combines two parts that are mutually exclusive.
> The first part selects all the indexterms, but qualifies them with a
> boolean
> expression to exclude all of them if $chunk.children = 1.
> The second part selects indexterms that are either immediate children of
> the
> current section, or a descendant of any child element that is not a
> section.
> This part is qualified by the opposite boolean expression, so only one or
> the other part is used.
>
> I didn't test this, so let me know if it doesn't work for you. There
> might
> be a glitch that I'm not seeing.
>
> Bob Stayton
> Sagehill Enterprises
> [email protected]
>
> --------------------------------------------------
> From: "Olsen, Morten Engelhardt" <[email protected]>
> Sent: Tuesday, March 19, 2013 11:14 AM
> To: <[email protected]>
> Subject: [docbook] Select chunk content from user.head.content template
>
>> As you may or may not know, I have started on cleaning our internal
>> Microsoft Help Viewer 1.0 transformation up to a point where it is
>> releasable to the public. However, in this effort I have come across some
>> issues.
>>
>> Some background;
>> The Microsoft HV1 format is the replacement for chm and hlp files. It is
>> based off xhtml with a set of header tags an some special magic. The set
>> of html and other content are zipped into a zip volume with the mshc
>> extension (Microsoft Help Collection or similar ☺). This file (called a
>> package) is accompanied by a manifest file with the extension msha. This
>> file can point to multiple packages, and this collection of packages is
>> called a book.
>>
>> Now to my first found issue;
>> The header for a html file needs to contain a set of special meta tags.
>> This is what the help system uses to generate positional/relational
>> information, indexing and content description. Some of these tags needs
>> to
>> contain information of the current chunk (e.g a set of <meta
>> name="Microsoft.Help.F1" content="myTopic" /> for all F1 content in the
>> current chunk). Currently we use indexterms with IDs to mark content for
>> F1 resolution, and the following template is called from
>> “user.head.content”:
>>
>> <xsl:template name="mshelp3.help.f1">
>> <xsl:for-each select="self::*//indexterm">
>> <xsl:if test="@id">
>> <meta xmlns="http://www.w3.org/1999/xhtml";
>> name="Microsoft.Help.F1">
>> <xsl:attribute name="content">
>> <xsl:value-of select="@id" />
>> </xsl:attribute>
>> </meta>
>> </xsl:if>
>> </xsl:for-each>
>> </xsl:template>
>>
>> However, the “self::*//indexterm” matches all indexterms below self, but
>> with a chunk depth of e.g.4, the content of self may be chunked into
>> separate files. So how can I select the content of only the current chunk
>> from “user.head.content”? The current situation is that F1 ids are
>> flowing
>> up in the chunking tree and usually hits on a higher level than were the
>> actual section exists.
>>
>>
>> Morten Engelhardt Olsen
>> Software Engineer / Tools Group / Atmel Corporation
>> Tel: (+47) 930 94 593
>>
>> The information contained in this email message may be privileged,
>> confidential and/or protected from unauthorized disclosure. If you are
>> not
>> the intended recipient, any dissemination, distribution or copying is
>> strictly prohibited. Please immediately notify the sender by reply if you
>> received this email in error. Thank you for your cooperation.
>>
>>
>
