Return-Path: 
 <forrest-dev-return-4107-apmail-xml-forrest-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org
Received: (qmail 91084 invoked by uid 500); 12 Dec 2002 13:44:10 -0000
Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:forrest-dev-help@xml.apache.org>
list-unsubscribe: <mailto:forrest-dev-unsubscribe@xml.apache.org>
list-post: <mailto:forrest-dev@xml.apache.org>
Reply-To: forrest-dev@xml.apache.org
Delivered-To: mailing list forrest-dev@xml.apache.org
Received: (qmail 91074 invoked from network); 12 Dec 2002 13:44:09 -0000
Received: from new-smtp2.ihug.com.au (203.109.250.28)
  by daedalus.apache.org with SMTP; 12 Dec 2002 13:44:09 -0000
Received: from p134-apx1.syd.ihug.com.au (expresso.localdomain)
 [203.173.140.134]
	by new-smtp2.ihug.com.au with esmtp (Exim 3.22 #1 (Debian))
	id 18MTdH-0003X4-00; Fri, 13 Dec 2002 00:44:08 +1100
Received: from jeff by expresso.localdomain with local (Exim 3.35 #1 (Debian))
	id 18MTdH-00033w-00
	for <forrest-dev@xml.apache.org>; Fri, 13 Dec 2002 00:44:07 +1100
Date: Fri, 13 Dec 2002 00:44:06 +1100
From: Jeff Turner <jefft@apache.org>
To: forrest-dev@xml.apache.org
Subject: Linkmaps (Re: URI spaces: source, processing, result)
Message-ID: <20021212134406.GF3340@expresso.localdomain>
Mail-Followup-To: forrest-dev@xml.apache.org
References: <20021212062719.GB3340@expresso.localdomain>
 <ADECJLDNBFNBOJBLKCMOAEEODLAA.rob@koberg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ADECJLDNBFNBOJBLKCMOAEEODLAA.rob@koberg.com>
User-Agent: Mutt/1.4i
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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