[Forwarded this private message to debian-doc as well, it may be of interest to others.]
"Joerg.Wittenberger" <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED]<URL:http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
