[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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%  

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  

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  

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  

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  

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.


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: