Linkmaps (Re: URI spaces: source, processing, result)

[Jeff Turner <je...@apache.org>]

On Thu, Dec 12, 2002 at 02:58:20AM -0800, Robert Koberg wrote:
> Hi,
> 
> > -----Original Message-----
> > From: Jeff Turner [mailto:jefft@apache.org]
> > 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
href="hello.pdf">.

> 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:

http://marc.theaimsgroup.com/?t=103444042500002&r=1&w=2

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:

<site>
  <index/>
  <primer/>
  <faq>
    <how_can_I_help/>
    <building_own_website/>
    <building_fails_on_subsequent_builds/>
  </faq>
</site>

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?".


--Jeff


> best,
> -Rob