forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <>
Subject [libre] UC-faqmanagement (was RE: [libre] use(full) how and when)
Date Mon, 15 Jul 2002 06:41:52 GMT
Hi all, and thx Diana and Steven for the input.
I'm splitting up the different use cases you proposed in different threads
(please feel free to throw other ones on the scene)

I'm hoping to discuss in some more detail how the usage examples would
actually work/look like from the end-user (both consumer, content-editor,
webmaster or whatever roles) viewpoint.
When we get some agreement on how it would look like we can evaluate if it
would be indeed usefull and tune the to be made redesign in a direction that
makes the end result easier to use and maintain.

So here's the first.

[libre] UC-faqmanagement.

Steven Noels [] wrote:
> I've seen a lot of so-called [summary] mails lately on cocoon-users,
> which eventually would need to be collated in faqs and codesnippet
> documents. Currently, we have a faq document which consists of one big
> XML document.
> Now imagine we just reserve a directory for faq-like documents, in which
> small individual XML docs are collected of which we produce a ToC-like
> view using libre. Nothing we can't do with the XPathDirectoryGenerator,
> of course, except that the XPDG is an all-or-nothing approach. Using
> libre, we can 'manually' add some entries (which really need to be
> listed in front) and have the rest handled by libre.
> After some time, having a directory with several tens/hundreds of these
> little files can become a burden. Now we just have to create some
> subdirectories according to certain categories and move our little
> snippets into the relevant subdirs afterwards.
> If we would use the book.xml approach here, we would end up with loads
> of manual maintenance. Using libre, most of it would be automatic.

doing the exercise of setting it up in practice to see what we really need:

I understand this view:
the person(s) responsible for the faq list, no longer builds one big xml
file but:
- creates smaller, independent files each on one faq-topic (being the
summarizing set of alternative/valid answers to the one <question> at hand.
- biggest joy in his/her/their life would be that they only need to give the
*.faq.xml file a name (any naming convention there?), drop it in a directory
and that it shows up in the big faq-list
- only if they want it to "jump the queue" and appear ahead of the
predefined order (which order would that be?)you'ld need to either create an
entry or dump it in another directory.

one proposed approach I see is the following:
**/faq directory of files now replacing the single faq.xml

all question-answer files take a similar naming convention that enables easy
sorting by date they were entered:
yyyymmdd.NN.some_recognisable_name.faq.xml where NN is a 2 digit sequence
number to allow for adding say a 100 faqs a day?

also inside the dir is the libre.xml file that
- lists by manually-coded entries that need to be at the top of the faq
- does not do any filtering
- does not do touch the default (alphabetic) sorting (or maybe just inverse
it so the newest ones are on top?)

something allong the lines of
  <entry location="20020713.01.important_howtolibre.xml">
      <xpath expression="//question/text()" />
      <property name="path" />
  <!-- more entries to be made here -->
  <auto> <!-- don't filter and just do alphabetic sorting -->
      <xpath expression="//question/text()" />
      <property name="path" />
    </href>  </auto>
could do the trick (in fact current release should do this -- with the
warning that this is  *not* a verified statement :-)

REMARK: have to admit that while writing this case, the duplication of the
<label>, <href> stuff seems a bit silly... should be a better way for doing
that. maybe an <attributes> section at the start declaring the way to
attribute both <item> and <collection> elements?

the libre-generator pointing to the starting faq directory would produce
some output xml looking like:

<collection label="faq">
  <item label="How should I use libre?"
  <item label="question from some file"
  <item label="question from some other file"

even the jumping-the-queue could be automised...
e.g. by having a naming convention that puts the file immeditately in some
[level] being e.g, high, medium, low:{level}.somename.faq.xml

then the libre.xml becomes:

  <!-- filter the *.high.* and the *.medium.* + apply just alphabetic
       which will place medium behind high anyway -->
      <property name="name" regex="\d{8}\.\d{2}\.(high|medium).\.*" />
    <label><xpath expression="//question/text()" /></label>
    <href><property name="path" /></href>
  <auto> <!-- without filter this will take the rest -->
    <label><xpath expression="//question/text()" /></label>
    <href><property name="path" /></href>

of course more digits in the prefix could indicate some numeric 'level' that
will be automatically sorted anyway.

if the to be produced navigation needs the actual directory levels, then we
just create

with a
  <entry location="high" />
  <entry location="medium" />
  <entry location="low" />


This almost sounds like something we could work on? More ideas?

(Diana, I persume your remark on dynamic sorting would very much apply here?
please clarify on which information you would ask from who, and in what form
in order to let "the system" provide just what precisely?)


View raw message