sitemap modularity

[Steven Noels <st...@outerthought.org>]

Dear all,

seems some of us are starting to have actual use cases for Forrest - good!

This is just to re-start the discussion we had earlier on sitemap 
modularity, i.e. having a root sitemap for content types we 'own' and 
manage, and some automounting sitemap setup for people wanting to customize.

If we want to go forward with this, I assume we will want to give them 
an example of this, perhaps using some common, but not too sophisticated 
content type such as FAQs.

There's a number of issues, though...

1) @skinname@ filtering/rewriting inside the Ant copy tasks prior to 
generation...
    - using Ant for customizing rendition behaviour seems like a big hack
      to me, and we should find some way around it, perhaps using sitemap
      parameters, maybe being set by those new input modules of Cocoon...
      opinions please
    - parametrization of XSLT stylesheets using the same mechanism seems
      like an equally big hack, too, and we should migrate this to proper
      sitemap aggregation, a process which depends on some configuration
      file inserting those as XSLT parameters, or something else
    - for choosing the skin to be used upon generation/for the webapp, we
      could also move the selected skin into a fixed location instead of
      moving them all and having to do this @skinname@ stuff

2) we should decide what to do with the 'community' section of Dia~a and 
David... should this stuff be moved into its own sitemap, or be made 
part of the core setup?

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