forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Koberg <>
Subject Re: draft howto dtd
Date Mon, 27 May 2002 19:07:33 GMT
Hi Ivelin,

Ivelin Ivanov wrote:

>Good points.
>----- Original Message -----
>From: "Robert Koberg" <>
>>On the book.xml (menu/site-structure) and index.xml (content piece), for
>>example: why duplicate link's href values - if you had access to
>>book.xml (the menu or site structure) you could reference links by ID
>>instead of a hard coded link. For example the content hard codes links
>>to faq.html or Why not have these in one
>>location (book.xml) and refer to them? It would be nice to reuse the
>>data provided by book.xml (perhaps even store more page level meta info
>>there?? show-toc, show-meta-data, show-on-nav - or at the folder level:
>>number-pages, show-on-nav - etc). Even better have book.xml be a
>>representation of the entire site hierarchy. Then you can recursviely
>>build paths to documents. For all the good book.xml does it could be
>>written straight into the XSLT (and included :).
>Can you suggest a concrete (preferably standard) technique for documents to
>use links from within book.xml?
Sure. How about something like this:

book.xml (I have an alternative if you are interested...)
   <menu id="f1234" label="Document Sample" folder-name="samples">
      <menu-item id="c3432" label="Samples Home" file-name="index.html"/>
      <menu id="f6234" label="Pipelines" folder-name="pipelines">
         <menu-item id="c7663" label="Pipeline 1" 
         <menu-item id="c8795" label="Pipeline 
2" file-name="pipeline2.html"/>

a content XML, say the cocoon home page:
  <title>jdfghjdfgh jsdfjksd</title>
  <para>Check out <link id="c8795">Pipeline 2</link> or go out to 
bubba's site to see this <link 

<!-- perhaps all you need is <link id="c8795"/>  and the label or link 
text can come from the book.xml, see the XSLT below for clues how this 
could be done -->

If you can pass the XML (nodeset) in as a param then you would not need 
the XPath document function. In a primary XSLT you bring the top-level 
param for the above config XML:
<xsl:param name="book-xml"/>
also make a key at the top-level for speed in accessing the correct 
<xsl:key name="menu-id-key" match="menu | menu-item" use="@id"/>
Then at some point you match a link:
<xsl:template match="link">
<!-- choose whether it is internal or external -->
   <xsl:variable name="href">
         <xsl:when test="boolean(@id)">
            <xsl:apply-templates select="$book-xml">
               <xsl:with-param name="link_id" select="@id"/>
         <xsl:when test="boolean(@out)">
            <xsl:value-of select="@out"/>

   <a href="{$href}">
      <xsl:if test="boolean(@out)">
         <xsl:attribute name="target">_blank</xsl:attribute>

<!-- change contexts to the book-xml nodeset (so you can use the key and 
travel the XML) -->
<xsl:template match="book">
   <xsl:param name="link_id"/>
   <xsl:apply-templates select="key('menu-id-key', $link_id)" 

<!-- recurse over the path to the document and provide the path info -->
<!-- something like this - not tested -->
<xsl:template match="menu-item | menu" mode="linker">
   <xsl:apply-templates select="parent::menu"/>
   <xsl:value-of select="@file-name"/>

<xsl:template match="menu-item | menu">
   <xsl:apply-templates select="parent::menu"/>
   <xsl:value-of select="@folder-name"/>

>It has been proposed that W3C Topic Maps can be useful.
have not looked too far into this :(

>How about using the document link tag like this:
><link href="document({$bookDocument})/menu/menu-item[@id='howto-step1'">
See above

>Where the bookDocument variable is passed in from the sitemap.
>This will require that the document files are not plain xml files, but xslt
>files instead.
hmmm... why do they need to be XSLT? Can it be passed in as a nodeset to 
a top-level param, since we can't use the XPath document function to get 
it from the filesystem.


>To keep things clean maybe the <link/> tag can be extended with syntax like:
><link href="book/howto-step1"/> or similar
>>I still don't see what is wrong with using import or include to bring
>>together many XSLTs into one. The cocoon way of performing multiple
>>transformations seems like way too much work when you want to break your
>>XSLT into component pieces for easy reusability.
>>I think you miss a *great deal* of the benefit of XSLT by not using the
>>document function and import/include. I can't seem to come up with a
>>good way to do the things I want to do without them.
>I agree that the map:aggregate in the sitemap is somewhat redundand.
>What are its advantages over passing the components as parameters to a
>normal XSLT page
>which includes them either through include/import or the document()
>The advantages that I see in the latter approach are that its utilizing XML
>It also allows use of namespaces in the aggregating document, allows
>references to validation documents,
>and everything else you can use in an XSLT document.
>Additionally the link referencing suggested above is natural.
>>I would love clear, explicit documentation on how to do things that are
>>commonplace in regular XSLT but are to be avoided when using cocoon.

View raw message