forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@indexgeo.com.au>
Subject Re: draft howto dtd
Date Tue, 28 May 2002 01:58:00 GMT
Hi Ivelin and Rob, i have an alert.

I do not know how far they are progressed.
However, Steven Noels and some of his colleagues
are working a Cocoon facility that they referred to
as directory-generator-on-steroids ... as a replacemnt
for book.xml

So what i am saying is ... Heads Up, be careful that
you do not waste valuable effort. I am not saying
that your discussion is not relevant.I have only
skimmed through it and thought that i had better
tell you about overlap. 

I think that there have been small discussions about
their work on both cocoon-dev and forrest-dev

Also i think that it would be a good idea for you
to change the subject title of this thread.
--David

Ivelin Ivanov wrote:
> 
> 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