forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <...@outerthought.org>
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 [mailto:shannon@apache.org] 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="..">
    <meta>
      <version>..</version>
      <other>..</other>
    </meta>
  </item>
</collection>

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

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
everything...


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,
no?

-marc=


Mime
View raw message