Re: debian meta data
[Forwarded this private message to debian-doc as well, it may be of
interest to others.]
"Joerg.Wittenberger" <Joerg.Wittenberger@pobox.com> writes:
> Besides that the dublin core is supposed to be at Wrapbit's related
> projects page, a nifty tool specialized in editing RFC-822 msgs from
> scripts (of any language) was one of the first things which made
> their way into a C impl in the rabbit project. Not that I think
> this is important by itself, but sometimes these kind of coincidents
> are signs. (BTW: I guess I need to learn a little more about the
> debian packages, I'll probably cut this tool out and make it smth
> stand alone. It seems to deserve that and might be useful to
> others.)
I'd really be interesting in getting a hold of a C implementation of
an RFC-822 parser. I could even help you package it up and distribute
it or something.
>> It is an error for one URL to have multiple metadata.
> I disagree. In the real live it's quite natural that the very same
> document has multiple meta data. Those can even express contrary
> statements.
> I don't know why you're making this restriction here. Maybe you can
> tell me. I guess it will come into the way later (but it could be
> enough for the debian documentation, if this was the concern).
> There are more than one reason NOT to use the file name for an
> unique identifier, maybe rethink that. A checksum like md5 seems to
> be of value here. --> Different versions have different ids and
> you'll need them. Sure the id should be hidden from the user.
Well, first off, I *do* recognized that, in general, a single resource
might have multiple representations as metadata. And I'd hate to
adopt entity restrictions which latter I have to drop.
However: I hate surrogate keys, that is, unique IDs that are made up.
I don't want to support them, I don't want them at all. They are not
inherently meaningful to people, therefore they are not meaningful to
the user, and make debugging and maintenance very difficult.
Furthermore: I forsee the document ID (in my scheme, something like
debian-policy/policy.html/index.html) enabling multiple
interpretations! For instance, "in the documentation area of the
package debian-policy, the file policy.html/index.html". This is
important to do because I think the documentation area is going to
move from /usr/doc to /usr/share/doc . Futhermore, it's important for
ultimate URN support. This would enable me to say
"debian:debian-policy/policy.html/index.html" or however one would
formulate it as a URN, and if the user doesn't have the package
installed, the URN server would redirect to a suitable mirror.
Probably what I should do is force, for relative URLs, the first
argument, "debian-policy" to be in fact the package name. If the
actual resource is *not* in the doc area of the package holding the
metadata, the developer should use an absolute file URL. I'm not sure
that this isn't too draconian. Let me think about this a bit more.
>> 2.1 Automatic Document Conversion
> This all sounds as if we should tweak the rabbit a little.
I'd love that. 'install-docs' *has* to be a quick fast program, and
small, since it's on or near abouts the base system. So you think we
could modify rabbit to reference some local document store (i.e., a
little database of metadata). I'll have to take a look at your code.
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: