forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Linkmaps (Re: URI spaces: source, processing, result)
Date Thu, 12 Dec 2002 13:44:06 GMT
On Thu, Dec 12, 2002 at 02:58:20AM -0800, Robert Koberg wrote:
> Hi,
> > -----Original Message-----
> > From: Jeff Turner []
> > Sent: Wednesday, December 11, 2002 10:27 PM
> <snip/>
> >
> > Here is an analogy with the seemingly uncontroversial 'linkmap' scheme.
> > How should 'linkmap' links be implemented?
> >
> > a) Have an explicit prefix, like <link href="site:/primer">
> > b) Have unprefixed links like <link href="primer">, and have the CLI open
> > the linkmap.xml file, and check if a 'primer' entry exists.  If so, treat
> > as a linkmap link.
> I am failing to understand why this is a concern of some post process. Are you
> not trying to transform one representation to another? To me, the 'linkmap.xml'
> should be accessed at transformation time to transform the link.

Yes.  The question is, should the link be <link href="site:/primer"> or
<link href="primer">.  Is the fact that "primer" is a linkmap id
explicit, or must Forrest deduce it.

Though remember, this issue is an analogy for the _real_ issue, which is
whether we should have <link href="file:hello.pdf"> or <link

> On the linkmap: I would not like to see a list of URIs (or URLs). Is forrest
> intended to be only for well established projects? That is, those projects that
> have their site architecture set in stone. Should forrest be used for projects
> that might need to rearrange the site structure? If it is for a new site/project
> then it would be nice to be able easily move things around without having to
> hand edit the linkmap to change the URI/URL string for each changed item. If you
> have a linkmap like:
> <folder name="docroot">
>   <page id="abcd"/>
>   <folder name="folder1">
>     <page id="f1abc"/>
>     <page id="f1bcd"/>
>     <page id="f1cde"/>
>     <folder name="folder11">
>       <page id="f1abc"/>
>       <page id="f1bcd"/>
>       <page id="f1cde"/>
>     </folder>
>   </folder>
> </folder>
> After you have created this initial structure, generate the site, and then some
> people look at it and determine it is not the best, usability-wise. It is
> determined that folder11 would be better served as a child of the docroot. Using
> a structure like the above you simply move the folder11 nodeset to be a child of
> the docroot. There is no need to rewrite strings telling where these things are.

Yes, certainly.

> The transformation finds the ID of the item in question and recursively builds
> the path as it is structured in the linkmap at time of generation.

There is a subtle difference between your site.xml and what I proposed as
a linkmap:

In site.xml, the XML structure models the directory structure, and
assigns IDs to nodes.

In linkmap.xml, the XML structure models the _information_ structure of
the site, and then the physical directory structure is mapped onto it.
So a linkmap might be:


Given this difference, it makes sense to use XPath (not node IDs) when
naming links.  Eg, <link href="site:/faq/how_can_I_help">.  Because it
_is_ a FAQ entry, and that won't change regardless of where it is
physically located.

> Now, I think the objection to this is that it is too hard to understand
> or do recursion to build these paths? Is that the problem?

No.. the linkmaps are still vapourware, but when it comes time to
implement them I'm sure a bit of recursion won't hurt.  The current
'problem' is (IMO) largely unrelated to the the linkmap concept, and
_totally_ unrelated to their implementation.  The relation can be summed
up as, "if we're going to have site: links all over the place, why not
have file: links?".


> best,
> -Rob

View raw message