Re: Re^6: Debian Metadata Proposal -- draft rev.1.4
On Wed, Jul 08, 1998 at 06:43:00PM +0100, Marco Budde wrote:
> Am 07.07.98 schrieb apharris # burrito.onshore.com ...
> APH> > And how would you describe all other documents with type? Using type
> APH> > will produce a lot of work for the package maintainers without any
> APH> > improvements for the users.
> APH> Unsubstantiated. It's an optional element. How can an optional
> APH> element create work for package maintainers, please explain?
>
> It will produce work if some maintainers use it. And a lot of maintainers
> will add the tag to their files. And for most documents it#s difficult to
> change the right type.
I don't understand the last sentence.
> I think that this tag is useful in a large distributed system like the
> WWW, because you don#t have a DDH maintained by one organisation. But we
> don#t have this problem.
It is very easy to do it right. After a few weeks, we can cut down the Type
field to a list of possible values that the maintainers can use. If nothing
fits, the field should not be used.
Marco, I get the impression here that you are objecting for the sake of
objection. You don't rise technical objections but assume that the average
maintainer is dumb and stupid. I think this is very insulting.
> APH> I propose to eliminate that and adopt a central document
> APH> store, rather than having display systems read docreg files.
>
> No, we#ve discussed this already. It should be possible to use dhelp on a
> non Debian system. And I need special organized databases. You can add an
> API to doc-base, no question. But (a) I don#t need it and (b) this would
> be a doc-base project and shouldn#t be part of the file format standard.
(a) I don't care what dhelp needs and what it doesn't. I want to get the
design right. Dhelp was a preliminary hack. At the moment, Debian
doesn't have a working documentation system, and so we have the freedom to
design a good one.
(b) The file format standard and the other parts of doc-base go hand in hand.
> APH> Marcus and I have raised a number of what I would consider crippling
> APH> objections to your proposed relative identifier scheme. I haven't
>
> ? I don#t see any real objection against my scheme. Something like Marcus#
> "I don#t like dot files" is no argument.
Huh, I am pleased to officially retract this one argument and point you to the
set of other objections I made.
I wonder why you only see the minor things I mention and never the really
important ones. What is a "real objection" for you, Marco?
> APH> > 1.) With your solution you can only support one subdir (/usr/doc).
> APH> > But we should offer support for every location (for example
> APH> > /usr/local/doc).
> APH> Untrue. Absolute URLs, including
> APH> file://localhost/usr/local/doc/foobar/ are allowable.
>
> Where#s the connection? Your URL points to the file on the local
> filesystem and not to the file on the system where the docreg file is
> installed. Ergo no solution.
>
> (Are you sure that your URL is correct? netscape uses file:/usr/local/?)
It is indeed valid. And, please, Marco: Make yourself informed about
identifiers, URLs and URNs before you participate further in this
discussion.
> APH> > 4.) Relative links are always better, html itself uses in most cases
> APH> > relative links! Or read the link chapter in the policy.
> APH> We propose to resolve relative links against a "path" of
> APH> /usr/share/doc:/usr/doc:http://www.debian.org/doc .
>
> That#s a very bad solution. This is (a) very slow (200% slower) and (b)
> how should I resolve something against http://www.debian.org/doc? And in
> Germany and a lot of other countries a Internet connection is very
> expensive.
This is not at all. slow. It will start a bit slower and then will go back
to 100% as soon as all packages made the transition. And this is only for
relative links. Absolute links are resolved in no time.
Marco, do you have still any clue what we are talking about?
> APH> Your system
> APH> doesn't allow this at all.
>
> Do you try to tell me, that the problems of your solution are advantages?
> Where#s the advantage to search several directories instead of knowing the
> right path? Sorry, but this is nonsense.
It is indeed nonsense. Please read my summarizing mail carefully. Think
about what an identifier is. Try to seperate absolute identifiers and
relative identifiers. They are not necessarily filenames, Marco.
And then try to comprehend why the Identifier will be absolute in the
repository. And why even the relative Identifier in Adam's proposal is
vrtually absolute (module FSSTND->FHS transition). Hint: Every package has
either its documents in /usr/doc *or* in /usr/share/doc, never both.
> Maybe it#s not a good idea, to use the filename as identifier. Our old
> solution (doc-base) hasn#t got this problem.
It is INDEED a BAD IDEA to use FILENAMES as identifiers.
And it is EXACTLY what YOU are trying to do with your "relative to the
actual directory" mis-concept.
Adams design uses URL-Identifiers, which are meant to be UNIQUE across the
network. And they are still unique when we say that relative links are
implied to be relative to file://localhost/usr/doc (or aequivalent).
The point is that they are STILL unique, when we use the path
/usr/share/doc, /usr/doc, because every package will only register in one of
both. This all fits very well, and has very little to do with filenames.
> APH> confusing for maintainers and difficult to support, and will lead to a
> APH> greater number of orphaned objects in your database. Why should file
>
> I don#t see that.
Do you see it now?
> APH> position determine the object identifier? I think most people will
> APH> find this suprising, opaque, and confusing.
>
> Why should we use a file name as identifier? This is always a bad
> solution.
You want to use a filename as an identifier, we want to use a unique URL
(maybe later URN) as identifier. Those are different, and the whole
discussion would improve greatly if you would learn this difference soon.
> Please stop telling such a nonsense. I can#t see any differences between
> your and my solution. Please explain this to me. Remember, HTML uses in
> 99% of all cases relative paths and not absolute paths!
This is not at all about HTML, Marco.
> Really? Please tell me how I can add for example
> /usr/lib/doc-base/foo.docreg to a tar archive. 99,9% of all tar archives
> uses relative paths!
You need an install program that moves the file, sets the URL identifier
(note: NOT the filename, see above) correct accoring to the document
location and you are done.
BTW: Our main concern should be Debian packages, not vendor packages.
However, our solution will work for all if the participating parties use URL
identifier, and not relative filenames.
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: