Return-Path: <KPiroumian@protek.com>
Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list forrest-dev@xml.apache.org
Received: (qmail 39552 invoked from network); 11 Jul 2002 15:37:28 -0000
Received: from relay.flagship.ru (213.221.9.5)
  by daedalus.apache.org with SMTP; 11 Jul 2002 15:37:28 -0000
Received: from POSTMAN.flagship.ru (postman.flagship.ru [213.221.9.130])
	by relay.flagship.ru (8.11.4/8.11.4) with ESMTP id g6BFbTH43604
	for <forrest-dev@xml.apache.org>; Thu, 11 Jul 2002 19:37:29 +0400 (MSD)
Received: by POSTMAN.flagship.ru with Internet Mail Service (5.5.2653.19)
	id <3DTNNF3Z>; Thu, 11 Jul 2002 19:38:51 +0400
Message-ID: <B6352CB87AA70442A1C6F49E6B658C9801EE9E@POSTMAN.flagship.ru>
From: Piroumian Konstantin <KPiroumian@protek.com>
To: "'forrest-dev@xml.apache.org'" <forrest-dev@xml.apache.org>
Subject: RE: sitemap issues
Date: Thu, 11 Jul 2002 19:38:51 +0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="koi8-r"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
Status: O
X-Status: 
X-Keywords: 
X-UID: 126

> From: Steven Noels [mailto:stevenn@outerthought.org] 
> 
> Hi all,
> 
> (I'll come back to my much-visited poll later on ;-)
> 
> We can't be everything to everybody, so I was thinking how we would 
> support some sitemap configurability for projects that are 
> depending on 
> our remote project building.
> 
> After re-reading the thread on cocoon-dev on automounting 
> subsitemaps as 
> a default, I think we should go that way, too.
> 
> I don't think we can foresee every pipeline necessary for 
> each project, 
> neither. When thinking of the src/documentation hierarchy inside 
> external projects, I thought we could only 'force' people 
> maintain the 
> root of that hierarchy according to our rules. For subdirs 
> inside that 
> documentation root, they should be allowed(/forced?) to 
> specify its own 
> sitemap. We must however list what components can be used 
> inside those 
> subsitemaps since we are in charge of maintaining our version 
> of Cocoon 
> and the jars it depends on.
> 
> So we would end up with the following hierarchy for external projects:
> 
> {some-cvs-module-root}
>    {src}  ----------------------> suggested documentation root
>      {documentation}  -------/
>        {content}  ----------/
>           {xdocs}  --------/
>             index.xml
>             book.xml (for the time being)
>             foo.xml
>             {dir}
>               sitemap.xmap
>               ...
> 
> And we add an automount pipeline similar to Cocoon's at the 
> end of our 
> sitemap:
> 
>      <!-- mount everything else -->
>      <map:match pattern="*/**">
>        <map:mount check-reload="yes" src="{1}/" uri-prefix="{1}"/>
>      </map:match>

So, as I could get, you are proposing to have some predefined sections (like
'FAQ', 'Download', 'Docs') which are controller by their subsitemaps and
have an additional automounting pipeline for other directories in the root
context? 

Can we concider that every directory in the root context is a 'tab'?

> 
> For our current documentation pool, I think the community 
> contributions 
> section by Diana needs to be changed according to this setup.

Yes.

> 
> In terms of tabs and subsitemap pipelines which depend on 
> core sitemap 
> resources (skinit and the like), I believe we have some 
> serious thinking 
> to do, however: can you refer to a (root)map:resource from a 
> (sub)map:pipeline?

Something like <map:call resource="context://skinit" /> should work, but I'm
not sure. Let's check.

> 
> What do you think? If we don't start cleaning up the sitemap 
> RSN, we're 
> heading for a trash dump :-)

I won't point you to the message where I've said this very thing using
slitghly different words, but seems that you got it at last ;)

Konstantin

> 
> </Steven>
> -- 
> Steven Noels                            http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> stevenn@outerthought.org                      stevenn@apache.org
>