[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Idea : common dir and tree (Rep:Re: Why not create packages?)
- To: <>, <>,
- Subject: Re: Idea : common dir and tree (Rep:Re: Why not create packages?)
- From: "Greg Ferguson" <>
- Date: Wed, 19 Jul 2000 10:17:34 -0400
- In-Reply-To: <firstname.lastname@example.org> "Idea : common dir and tree (Rep:Re: Why not create packages?)" (Jul 18, 9:12pm)
- Resent-Date: Wed, 19 Jul 2000 10:16:48 -0400 (EDT)
- Resent-Message-ID: <n6rJF.A._9.7hbd5@murphy>
On Jul 18, 9:12pm, <email@example.com> wrote:
> Subject: Idea : common dir and tree (Rep:Re: Why not create packages?)
> [ plain text
> Encoded with "quoted-printable" ] :
> Perhaps LDP should specify a distribution-neutral
> > location for all the HOWTOs, such as /opt/doc
> We have been talking about this with KDP and GDP.
> Basically, for a unified documentation browser/search
> engine, we need a standard.
> My idea would be putting the following hierarchy in a
> dir, for ex /opt/doc :
> lang/de (etc)
> We could just provide link for dirs (for ex,
> /usr/man/man1 to man/man1) or for files (for ex
> /usr/doc/XXXX in txt/XXXX) or put plain files in that
> dir, as you suggested.
> In both cases, /opt/doc would look the same on each
> distribution, wherever the documents are really put
> in, and a documentation browser or a hand browsing
> would be very easy, all the documents being available
> in a single dir..
> Likewise packages would only have to add their
> documentation there to be automatically added to the
> browser "index" and "search base", regardless where
> it is installed.
> For ex, if staroffice did provide pdf documentation
> in /usr/doc/some/lost/directory/somewhere/doc.pdf, it
> would be as simple as providing a link in
> /opt/doc/pdf/staroffice to add its documentation to
> the database.
I'll throw out what we came up with at SGI. I wrote a short
paper on this topic (SGI's linux documentation delivery), and
*tried* to maintain and use whatever standards were available.
Granted, these conventions are targetted more toward "manuals",
but nonetheless, I/we tried to address some of the issues
Guylhem brings up (such as resource discovery).
Books are installed in:
Within each specific book instance directory there is an XML-based,
metadata-rich, Document Description File (DDF). That file contains,
among other things, information about each of the various available
formats for the content piece (HTML, PDF, Postscript, etc.).
Ideally a search/browse engine would crawl, examine, and collect
up the various DDF files that are available and use those
to trigger indexing and catalogging of data, etc. -- very similar
to the concepts used in the Dublin Core, metalab's OMF, etc.
No sym-links, nothing of that nature required. The difficulty
lies in knowing where to "find" these resource-description files.
Greg Ferguson - s/w engr / mtlhd | firstname.lastname@example.org
SGI Tech Pubs - http://techpubs.sgi.com |
Linux Doc Project - http://www.linuxdoc.org |
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org