[projectaon] Re: <bookref>
- From: Jonathan Blake <blake.jon@xxxxxxxxx>
- To: projectaon@xxxxxxxxxxxxx
- Date: Mon, 26 Dec 2005 15:14:29 -0800
On 12/25/05, Thomas Wolmer <angantyr@xxxxxxxxx> wrote:
> > [ ] Jon - clarify the intentions with <footref> and <bookref>
> > I also noticed that the <bookref> element is not supported by the XSL
> > either. Am I right in assuming that <bookref book="$book"
> > section="$section">blah blah text</bookref> shall be transformed into
> > <a href="../../$series/$book/$section.htm">blah blah text</a>, where
> > $series is always the same as for the book you are transforming and
> > $section defaults to "title" if it's left out?
>
> No wait, we don't have access to the series identity. Better than
> provising it as a parameter or parsing it out from something else,
> would be to let $book include the series, e.g. "lw/11tpot". At the
> same time that one can pretend that this is a logical name that only
> accidently happens to coincide with an ugly file path, it also gives
> the benefits that:
>
> * One can refer to books in another series.
> * Any future foreign language editions where book #X in series A and B
> both have the same abbreviation won't have to come up with some
> contrived solution for this.
>
> My possibly dodgy XSL code for this:
What do you think of providing an attribute to override the default series?
<bookref series="gs" book="01gstw" section="sect333"/>
> The current XSL template for <a href="..."> has handling of the 'id'
> attribute. What is this for? I cannot find any place where it is
> currently used.
It's there in case we want to have an element that specifies both an
anchor and a link. We may never use it, but I'd feel better keeping it
there in case we do need it later.
--
Jon
Other related posts: