> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > I like this idea, we need to think about this.
1) the 'we' was 'forrest', not outerthought
> I have the impression that you guys might be caught in the good old
> "don't who till is ready" ego trap with your 'libre' effort. Release
> early and often means also 'release when it barely does anything' so
2) touche :-(
point is that this thing has been sitting for quite some time on our
harddisks (it's already more or less integrated in my local copy of
forrest AAMOF), but since I said to my colleagues that I wanted to
submit it to forrest, we have been discussing refactoring and some
additional features ever since :-(
I'm also aware however of the fact that providing a functional codebase
helps with the adoption of new components, and we could go on endlessly
in RT-mode if we don't come up with a codebase to start with. After all,
Forrest has been mostly dead in the early days (sic) until Nicola and I
jumpstarted it with the addition of the early centipede codebase, which
was already pretty much cooked up prior to committing it
> that people can interact with you *before* you spend months
> developping
> and find out that many things that you considered *very cool*
> are simply
> not needed anymore.
agree, we are anxiously trying to balance momentum and good design
practices, and you know momentum is a prime mover & shaker in OSS
projects. The result *will* be released under an Apache license however,
whether it is used within Forrest or not, hopefully as being part of
Forrest or Cocoon, or on SF. While the scope of libre is much smaller
than the S&N portal contribution to Cocoon, its genesys should be
comparable: it was mostly finished intra muros before being released as
a contribution.
> In fact, I don't want the book.xml to be removed by a
> generator because
> no matter how powerful the generator is the book.xml file can contain
> much more metadata than any file system... and placing site-related
> metadata (such the one I suggested above) inside the document and have
> the generator extract it (a-la XPathDirectoryGenerator) seems like the
> wrong approach to me since it mixes concerns between the document
> authors and those who manage the site (which normally have different
> concerns).
-1
I hate book.xml from a user's POV. It's non-intuitive, duplicates
information, yet another thing people need to learn before they can
trust project documentation to the Forrest service, etc...
For simple document collections, it should be sufficient to put files in
a directory structure, and extract sequence and labeling from the
filename or by applying XPath onto the files. To do so, we have a simple
approach, configured using a little configuration file libre.xml, which
you could compare with .htaccess
It's all under reconsideration right now, but what we have working
currently is this:
libre.xml config file in content/xdocs:
<libre xmlns="http://outerx.org/libre/config/0.1">
<auto>
<filter logic="normal">
<property name="name" regex=".*\.xml"/>
</filter>
<label>
<xpath expression="/document/header/title/text()"/>
</label>
</auto>
</libre>
Output of our libre generator:
<collection xmlns="http://outerx.org/yer/hierarchy/0.1">
<item/>
<item label="Contribution to Forrest"/>
<item label="The document-v1.1 DTD"/>
<item label="Forrest dream list"/>
<item/>
<item/>
<item label="Welcome to Forrest"/>
<item label="The Apache Software License, Version 1.1"/>
<item label="Mailing List Archives"/>
<item label="Mailing Lists"/>
<item label="The Forrest Primer"/>
<item label="Who we are"/>
</collection>
As you can see, there are still issues (like directory handling in the
above example, which we are addressing), but this would mean a lot of
the information which now has to be hardcoded in book.xml can retrieved
from the documents itself.
We have basically three actions we do on a hierarchy (and this stuff is
being componentized so that we could implement this also on top of
non-filesystem hierarchies like a WebDAV resource):
- filtering
- labeling
- sorting
all three of them based on xpath expressions, resource properties
(filename, mod date, etc) and regexes on these properties, with and'ing,
or'ing and not'ing for filters.
On your SoC remark: you're right, and maybe we will still need such an
additional metadata config file for a filesystem repository, but WebDAV
resource meta-attributes also move this responsibility to the individual
resource maintainer, and not to the collection manager, if my
assumptions are correct.
> I might be totally wrong and I'd love to be because I hate raining on
> somebody else's party (I'm abusing this metaphor today) but your "*we*
> need to think about this" rang a bell in my head.
you and me and other forresteers, thus, not 'we' ;-)
<aside>
> I still don't understand why we need to incorporate changes and todos
> into a project description file.
and I can only agree with that.
</aside>
Hopefully we find time to act upon our promises, you know we are trying
really hard ;-)
</Steven>