forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <>
Subject [libre] UC-different distro builds (was RE: [libre] use(full) how and when)
Date Mon, 15 Jul 2002 06:41:53 GMT
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-different distro builds

Diana Shannon [] wrote:

> Here's what I hope we can accomplish -- in part -- with libre:
> 1. Generating different distro builds based on version (release
> #/beta/alpha, etc.), complexity (with or without: docs, samples)
> This assumes some meta content within docs about code dependencies which
> libre's xpath capability would examine while constructing data for such
> menus/indexes/etc.

Diana, help! You've lost me.
What exactly do you mean by different distro builds?
(I'm off-line when writing this, have no chance to check in elder
discussions on this)

It more or less sounds like documents would have metadata in them describing
- the version(s) of the software they apply to
- the target audience?
- ....

If my understanding is correct, then you're the one that really prooves the
need for dynaimc element-generation... (Steven and I discussed this before,
but didn't see a real need for anything else then attributes)

up to now the <item> and <collection> elements in the output can only
dynamically get some attributes like @href and @label that are based upon
String values to be read from the file-source they actually point at. (is
also why there is /text() in the xpath expressions we used up to now)

This would require for some new libre syntax (and code)... giving it a go:

this <meta> section inside the document should then just probably be copied
inside the libre output? Hoping that something like

<collection href="..">
  <item label=".." href="..">

would be generated based on a libre.xml that indicates:
      <href><property name=.. /></href>
      <label><xpath name="/doc-root/title/text()"></label>
      <xpath expression="/doc-root/meta" />

and then parameterized transformers could filter out what you actually want
in your navigation/toc based on tests for the values in the meta stuff
or even produce some sort of bill-of-materials that transforms into loads of
<cinclude> to be actually read into the bigger whole (for producing the pdf
manual e.g.)

we're mixing documents here, so I think my
fast-go-for-understanding-what-you-mean needs an update with some
namespacing in there.

is this a bit what you expect?
if so do you see a nearby usefull testcase to set this up in practice?
trajectory to doing/testing this should not need to wait on a full agreement
on the <meta> contentmodel... we could have a shot at a testversion of

only selfreflecting remark to make here and now, is the fact that you
probably could do all of this with the xpath directory generator as well,


View raw message