forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: draft howto dtd
Date Tue, 28 May 2002 00:39:19 GMT

Rob,

you guessed right, sorry I wasn't clear.
I meant that the reference to the book.xml files can be easily made
available to the other documents.
And yes your suggested syntax makes sence to me.

<xsl:param name="bookDocument"/>
<xsl:variable
   name="book-xml"
   select="document($bookDocument)/book"/>

Then referencing in documents can be as simple as:

<link href="{book-xml/menu/menu-item[@id='howto-step1]/@href}'">

or even

<link href="{book-xml//*[@id='howto-step1]/@href}'">

Provided ids are unique.

That is when the documents are allowed to use xsl (why not?).

If we prefer to keep documents strictly static, then your suggestion is a
valid solution.
I would only prefer to use the attribute names as:

<link href="http://good old method">

and something like

<link book-href="'howto-step1"/>


What do others think?


Ivelin



----- Original Message -----
From: "Robert Koberg" <rob@koberg.com>
To: <forrest-dev@xml.apache.org>
Sent: Monday, May 27, 2002 3:55 PM
Subject: Re: draft howto dtd


Hi again,

A couple of things i want to mention after rereading this...

the book.xml should have the cocoon folder-name so it can resolve to it
instead of the docroot, for example:

<book id="f1" label="Cocoon" folder-name="cocoon">
  <menu id="f1234" label="Samples" folder-name="samples">
     <menu-item id="c3432" label="Samples Home" file-name="index.html"/>
etc...

Also, I am thinking you meant the the book-xml param might be a string
with a relative or full path to the book.xml file??

If so, then instead of:
<xsl:param name="book-xml"/>
use:
<xsl:param name="bookDocument"/>
<xsl:variable
   name="book-xml"
   select="document($bookDocument)/book"/>

Does this make sense?

-Rob


Robert Koberg wrote:

> Hi Ivelin,
>
> Ivelin Ivanov wrote:
>
>> Good points.
>>
>> ----- Original Message -----
>> From: "Robert Koberg" <rob@koberg.com>
>>
>>
>>> Hi,
>>>
>>> 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 http://xml.apache.org/cocoon. Why not have th1?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...)
> -----------------------------
> <book>
>   <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"
> file-name="pipeline1.html"/>
>         <menu-item id="c8795" label="Pipeline 2"
> file-name="pipeline2.html"/>
>      </menu>
>   </menu>
> </book>
>
> a content XML, say the cocoon home page:
> -----------------------------
> <article>
>  <title>jdfghjdfgh jsdfjksd</title>
>  <para>Check out <link id="c8795">Pipeline 2</link> or go out to
> bubba's site to see this <link
> out="http://www.bubba.com/example.html">example</link>
> </article>
>
> <!-- 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
> menu{-item}:
> -------
> <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:choose>
>         <xsl:when test="boolean(@id)">
>            <xsl:apply-templates select="$book-xml">
>               <xsl:with-param name="link_id" select="@id"/>
>            </xsl:apply-templates>
>         </xsl:when>
>         <xsl:when test="boolean(@out)">
>            <xsl:value-of select="@out"/>
>         </xsl:when>
>      </xsl:choose>
>   </xsl:variable>
>
>   <a href="{$href}">
>      <xsl:if test="boolean(@out)">
>         <xsl:attribute name="target">_blank</xsl:attribute>
>      </xsl:if>
>      <xsl:apply-templates/>
>   </a>
> </xsl:template>
>
> <!-- 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)"
> mode="linker"/>
> </xsl:template>
>
> <!-- 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:text>/<xsl:text>
>   <xsl:value-of select="@file-name"/>
> </xsl:template>
>
> <xsl:template match="menu-item | menu">
>   <xsl:apply-templates select="parent::menu"/>
>   <xsl:text>/<xsl:text>
>   <xsl:value-of select="@folder-name"/>
> </xsl:template>
>
>
>
>
>
>> It has been proposed that W3C Topic Maps can be useful.
>> http://www.gca.org/papers/xmleurope2000/papers/s11-02.html
>>
> 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.
>
> best,
> -Rob
>
>> 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()
>> function.
>> The advantages that I see in the latter approach are that its
>> utilizing XML
>> standards.
>> 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.
>>
>>
>> Cheers,
>>
>> Ivelin
>>
>>
>>
>>
>>> 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.
>>>
>>> best,
>>> -Rob
>>>
>>>
>>>
>>
>
>





Mime
View raw message