Re: Debian Metadata Proposal -- draft rev.1.4
Am 01.07.98 schrieb apharris # burrito.onshore.com ...
Moin Adam!
APH> Ok one and all. This is my proposal for Debian Metadata, which is
Fine, your proposal, but haven#t we talked about an open solution
developed by several people?
Why have you changed the whole concept without asking the other developers
:((?
APH> Marco, would you be willing to help me work on the API and thinking
APH> about how to attach a database backend a la dhelp ?
Arhhh. Could we please finish one thing before starting another? At first
we need a *file format*.
APH> * work out the install-docs hooks mechanism for backwards compat
APH> support of dhelp and dwww
We don#t need that for dhelp. As I#ve said several times, dhelp will parse
the new file format itself.
APH> * work out the API for a better (no shadowing of data required)
APH> dwww/dhelp etc working right out of the document store (I need
APH> lots of help here)
I#m not interested in such an API for dhelp, because I need a special
structure. And we had discussed this already: dhelp will read the docreg
files itself.
APH> This manual contains a guide and a reference to the Debian Metadata
APH> Project.
A single person project :(?
APH> 3.1.2. The SCHEME Qualifier
APH> ----------------------------
APH>
APH> The `SCHEME' qualifier indicates what notational scheme the content
APH> is encoded in. This qualifier is usually not available to the
APH> maintainer for manipulation, since there is only one reasonable
APH> scheme for an element in the Debian environment.
APH>
APH> The default scheme is generally `freetext'. Other elements have a
APH> scheme of `URL' or `ISO.636'.
Whatfor does we need this?
APH> installed). In such cases, for the ease of the maintainer, a
APH> relative URL may be used. The implied basepath in such cases is
APH> `file://localhost/usr/doc/'.
No. We had discussed that topic several times.
APH> Currently, the domain of allowable values is
APH>
APH> * howto
APH>
APH> * faq
APH>
APH> * manual *(i.e., manual for software)*
APH>
APH> * reference
APH>
APH> * specification
APH>
APH> * tutorial
[ ... ]
I don#t understand that. We don#t need that, because for this purpose we
have got the section tag.
APH> * Subject
Why have you changed the name of this tag?
APH> * Description
APH>
APH> * Language
APH>
APH> * Creator
Ok.
APH> * Rights
Do we need this tag?
APH> A URL used to uniquely identify the resource. If the URL is a
APH> relative URL, it is relative to the location
APH> `file://localhost/usr/doc/', as described in subsubsection
No, the local URL should relative to the positing of the docreg file. For
example a user could use dhelp to build a structure of his own documents.
APH> Title
APH> LANG
APH> can set
Not necessary, the title should be in the language of the document.
APH> docreg files must be placed in the `/usr/share/doc-base/docreg/'
No, no, no. This makes it impossible to use docreg with relative paths.
I#ve showed you the disadvantages of this solution several times. This is
a very bad solution.
APH> subdirectory. By convention, this file should be named the same as
APH> the package, i.e.,
Sorry, but a lot of package will include more than one docreg file.
APH> is not enforced; however, these file names must be globally unique
APH> across all packages.
Right and this is one problem with this solution. What#s your problem with
my solution: docreg in /usr/doc/<foo>?
APH> The Document Store, in `/var/state/doc-base/docstore', is a file
APH> containing the collected information about all documents currently
APH> on the system. This file is in the same format as the docreg files.
???
1.) This docstore is the database of *your* docbase program. It shouldn#t
be part of a file format standard. Sorry.
2.) Why should we store one information twice?
APH> The Document Store file may be processed by the doc-base system into
APH> a more optimized system as well, such as Berkeley database file. To
APH> be determined.
This is not part of the file format -> remove it
-------------------------------
I#m missing the tags for adding new sections and their description.
Please tell me, if you#re interested to develop one common file format for
all programs or not. At the moment I#ve got the impression, that you#re
developing something for your system.
If you#re interesed in one format you should add the proposals of the
other developers. If you#re not interested, I#ll create my one file
format.
We#re talking about a very small file format for several month without any
results. This is really bad.
cu, Marco
--
Uni: Budde@tu-harburg.de Fido: 2:240/5202.15
Mailbox: mbudde@hqsys.antar.com http://www.tu-harburg.de/~semb2204/
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: