[libre] UC-dynamic sorting (was RE: [libre] use(full) how and when)

[Marc Portier <mp...@outerthought.org>]

As explained elsewhere I'm splitting up the different threads here...
All should join again when we get a better feel of the various needs and how
to combine them in the solution.

[libre] UC-dynamic sorting

Diana Shannon [mailto:shannon@apache.org] wrote:

> Here's what I hope we can accomplish -- in part -- with libre:
>
> 2. Dynamic sorting capabilities for users to re-arrange
> menus/indexes/ToCs (e.g. by modified date, author, topic, etc.) as
> needed. In other words, why should we (the royal we) assume we know how
> best to organize the content for users.


Diana, please define 'user' and 'dynamic' :-)
I have the impression you talk about browsing-end-users / content-consumers,
right?
How do you see them telling 'the system' which ordering they prefer? How
dynamic and freely choosen would that be?
Are you implying a runtime-cocoon or not?

If things are less high up in the sky, maybe there is some studd we could
already do:
Some ideas this is introducing on my side is to maybe have more then one
libre.xml file in a directory... so we have some libre.mode1.xml and a
libre.mode2.xml that defines another way for looking (==ordering and
filtering) at the same children of that directory... in fact the generator
already has a parameter to specify which filename to use as 'libre.xml' so
you could invent a URI that points to the generator and provides the [mode]
part to introduce into some param looking like: libre.{3}.xml

the different aspects to sort on then just need to be
- matching clear file properties (modif date)
- retrievable from well thought of filename-patterns that allow for
separatly matching/retrieving/re-arranging them
- retrievable xpath metadata content from the

(by the way the approach with the different libre.mode-style.xml could be an
alternative for producing the different distro-builds as well?)
I guess in these cases providing different top level libre.xml's would beat
the different all level book.xml's... it does expect us to find a formal way
for separating all aspects to sort/filter/group on, AND a logical place
(reflecting correct roles) to edit those aspects (inside the xml of the doc,
the filename, other file attributes,...)

REMARK: currently the libre thing always acts like the libre.xml file
doesn't exist.  Maybe it would be better to use the standard filesystem
hiding techniques (file property on winnt and start with . on unix?) so we
can hide all the libre.mode.xml files iff that would be required.

Other thing to think about: Libre will not (at this stage) introduce new
<collection> 's in the output unless there is actually a matching directory
level.  So looking differently at something does not allow introducing other
nesting/hierarchical levels... if one would really like that, please help
think about configuring that?

-marc=