Re^14: Debian Metadata Proposal -- draft rev.1.4
Am 29.07.98 schrieb apharris # burrito.onshore.com ...
Moin Adam!
APH> the system was doing mandatory link integrity; so expressing that
APH> you're a relation of a file which no longer is actually somewhere else
APH> is not a big difficulty for me. You seem to think it's an absolute
APH> nightmare situation whereas I don't.
Ok, you see the problem. Why shouldn#t we solve this problem? My prosposal
is a nice solution without any problems. So why shouldn#t we use it? I#m
using my file format proposal for my latest alpha version of dhelp_parse
0.4.x and the results are not bad :).
APH> > you change the identifiers.
APH> That's the risk with URLs!
But we#re not using URLs for local files!
APH> I'm willing to live with that, until we
APH> have a URN system, or better yet, something based on XLink (drool
APH> slobber).
Again, I#m not interested in using a URN system, because it#s 100%
useless.
APH> The problem I have with your system is that it locks out URNs, URCs,
APH> and other potentially useful ways (ISBNs) of identifying resources.
No, that#s not true. I#m using the Identifier tag as an identifier for a
docreg element and not for a document. For example you could have to
versions (PS, HTML) of one book. And so we can#t use the ISBN number as
identifier.
And you could of course use URNs for the "File: " line. Maybe we should
use another name for "File: " like "URL: ".
APH> However, I don't want to appear to be completely oblivious to your
APH> suggestion. How about I leave the syntax of the "Identifier" the same
APH> and add as well an optional "Debian-identifier" element for those who
APH> want to define persistent IDs. The in the "Relation" element or
APH> whatever you could use the proprietary URL
APH> "debian-id:<package>/<identifier>" syntax to notate this. This way
APH> the whole thing is optional....
Right and that is bad. I#m working on a translation document, I have to
ask the maintainer of the original document to release a new version with
this debian-identifier.
APH> Would this sort of thing suffice?
No, I don#t see your problem with my solution. The unique identifier
shouldn#t be optional. I don#t understand, why you like using filenames as
identifier. This is not required by the DC "standard".
The identifier should be unique and pseudo persitent in the docreg system.
That#s why we should use your debian-id als "Identifier: ".
APH> > Why? They have to be unique and the package maintainer shouldn#t change
APH> > the IDs of documents.
APH> How do you propose we *enforce* this? We can't. That's another
We don#t enforce but propose it. The maintainer should use something like
for example "<package>/<doc filename>" or "<package>/<title>". Where#s the
problem?
APH> reason why I don't like your scheme; I feel my comprimise solution is
APH> ok though.
I don#t see any differences for this topic.
APH> * no need to maintain global namespace of uniq ids (my comprimise of
APH> "debian-id:<package>/<identifier>" solves this)
Sorry, but you#re 100% wrong :). I#ve suggested to use
<package><free name> as identifier. So where#s the need to maintain a
global namespace of uniq ids? I don#t see that.
But with your solution you#ve to maintain it! If to packages add the same
URL (for example to www.debian.org) you have got a problem!
APH> Surrogate, globally unique keys are not an idea I want to foist on the
APH> world, especailly w/o a strong centralized mechnanism. My comprimise
APH> is to allow a light-weight translation system intead, and keep it
APH> optional.
Sorry, but I don#t understand your arguments. For the package maintainers
there#s no big difference between both proposal. But my proposal offers
some additional advantages.
APH> > What should I see above? I#ve proposed a unique ID and a file tag. I#ve
APH> > never proposed a URN system for documents.
APH> Why not? You should!
No, we could talk about URNs, if there#s support in the WWW browsers. But
using CGI-scripts or apache#s rewrite module is useless for a local
system.
APH> > Your proposal uses the identifier as URL/file. And this is a real bad
APH> > idea and this breaks the DC idea.
APH> Not at all. The DC system makes no claims in the persistance of the
APH> identifier, and requires no such persistance (though it's always
APH> nice).
That#s right and I think that this is a bug. A lot of people uses URLs as
identifier, but this is 100% nonsense.
APH> BTW, you know that DC is on the IETF standards track now, right?
I don#t know. Is that important? Again, my proposal doesn#t break the DC
standard.
APH> > P.S.: I#ve started to develop dhelp 0.4.x
APH> Excellent. Please let us know any flaws in the system your
APH> implementation work leads to.
At the moment there#re no problems, but I#m using my proposal (File:
(relative), Identifier:, docreg in /usr/doc).
APH> I'm starting the parsers already too.
Fine.
APH> Sorry they are all in perl still since my time is so short. Marco
I#ve got the same problem :). There#re some nice exams this month and next
month I#ll move to Manchester, UK :).
APH> thinks they *must* be in C. Any porters volunteer? Otherwise it
APH> probably won't happen for a while.
You could of course use my parser. It#s only one small function.
At the moment I#ve got real problems with libdb :(. Its documentation 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: