Re: Debian Metadata Proposal -- draft rev.1.4
Hi folks, here I am!
With unquoted parts, I agree (or didn't read carefully enough :) ).
On Wed, Jul 01, 1998 at 02:27:47AM -0400, Adam P. Harris wrote:
>
> 3.1.2.2. Concerning the Debian Type Scheme
> -------------------------------------------
>
> The Debian Type scheme is the set of allowable values (that is, the
> *domain*) for the content of the `Type' element. This scheme is very
> volatile and experimental, but we encourage you to use it and to offer
> comments on its use. Of course, the `Type' element is completely
> optional.
Well, this is a great idea. It makes the design of the DDH more flexible.
For example, a section for howtos can be provided and all "Type: Howto"
documents can be put there (in addition to the real Subject: field).
This can even be subject to user configuration (where to put them) in a
later, more developed version (I look in the future here).
> Resource types, it must be remembered, are orthogonal to both the
> `Subject' and `Format' elements. So, the `Type' element can be thought
> of as the generic *class* of resources, which is not related to its
> particular media or subject matter.
This is why it was such a dorn in my eye in the DDH. This Type: field
provides an orthogonal sorting/indexing/structuring. This is very
functional.
> 3.1.2.3. Concerning the DDH Scheme
> -----------------------------------
I guess this is very easy. The DDH is just a hierarchic tree. So, the
Subject: field can be something like:
Subject: debian/devel/pack
for packaging documents. The seperator may change ("-" instead "/" ?), but I
don't think it's very important.
What values are *valid* and should be used with a certain document is a
completely different matter, and will be covered by the DDH document(s) I
shall propose soon.
> 3.2. Metadata Elements
> -----------------------
>
> In Debian Dublin Core, certain elements are required, some are
> optional, and some are ignored as insignificant. As a rule, the adage,
> "be liberal in what you accept and conservative in what you emit"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> applies to the system.
I like this approach. Maybe school teachers should comply with it, too :)
And politicians.
> Title
> LANG
> can set
You said this is a mistake. I don't think so. If you buy a german book, it
always has a different title than the original (if the title is written in a
specific language).
I think we should allow different titles for documents. Most title won't
change anyway ("PostScript" -> "PostScript", but "What is PostScript" ->
"Was ist PostScript", assuming EN->DE). According, to the adage above, we
should allow this.
> Subject
> Where this document is situated in the Subject Catalog. For
> Debian, this Subject Catalog is the *Debian Document Hierarchy*,
> which see.
>
> SCHEME
> Debian, indicating the Debian Document Hierarchy
I think the DDH will fit nicely in this proposal. Adam, thank you for your
work!
> Format
> The format of the document, indicated as a MIME type, for
> example, `text/html'.
A reference to where I can find a description of MIME syntax would be nice
here (is it a RFC?).
> Date
Adam, please be a bit more verbose about the date field: Is it
year-month-day or year-day-month? To avoid confusion, this should be noted.
Or choose an example witha day > 12 :)
> 4.3.2. Field Sizes
> -------------------
>
> Field size limits are imposed on fields in order to facilitate a
> straight-forward database driven interface and hopefully help
> security. These size limits are checked at install time
> Identifier 80
> Title 80
> Subject 80 (multiple elements combined)
I think this is too less. For Subject: fields with entries in three
locations of the DDH (I didn't encounter one yet, but it *could* be useful),
this would be too low (because it would be locations deep within the DDH.
Maybe it would actually fit, but we should not only be lucky, but double the
value from 80 to 160.
> Format 40
> Description 1024
> Language 2
Currently we don't support de_DE etc, but maybe in the future? Why not bump
it to 5?
> Creator 200 (multiple elements combined)
This would be enough for three people, at most four or five. This should be
enough in most cases, but who knows?
How serious are the numbers listed here? What disadvantages would it mean to
increase the values a bit?
> 4.3.3. Weaknesses of the File Format
> -------------------------------------
>
> One weakness of the format is that there is a lot of repetetive
> encoding of identical information. The `Description' field
The sentence seems to be interrupted here. Work in progress?
I don't see too much redundation, btw.
>
> 5. Debian Metadata API
> -----------------------
>
> A simple C API, probably with Perl and Python wrappers, will be
> provided for the benefit of programmers wishing to make use of the
> local document store.
Maybe this should be in a different document, together with the other
sections about the docreg store (as Marco already suggested).
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: