Re^6: Debian Metadata Proposal -- draft rev.1.4
Am 07.07.98 schrieb apharris # burrito.onshore.com ...
Moin Adam!
APH> > As I read
APH> > the Dublin Core Homepage Dublin Core will never be a standard. The team
APH> > is working on RDF (XML based), see www.w3.org.
APH> Marco, yet another unsubstantiated claim. Sure, they'er working on
APH> RDF; that's a major reason why I chose them. I suggested in Feb to
APH> use XML as the transmission format and was shouted down. It doesn't
Right, because XML is to complex for our small problem. Once again, I
don#t object to use Dublin Core. But it#s simply not true, that it#s a
standard. At the moment there is no standard of the web.
And as I read the Dublin homepage Dublin Core is not only for the web.
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 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.
APH> Putting the same info, shadowed in multiple places, is exactly what
APH> dhelp does.
??? That#s wrong.
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.
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.
APH> So where's the beef?
Read the mails I#ve posted yesterday.
APH> > We don#t need it.
APH> How will you enable the functionality of recreating a document store
APH> (i.e., the database in dhelp) from scratch? I submit this is a
dhelp_parse -r
APH> crucial requirement for debugging, and dhelp contains a number of
APH> critical bugs because
Nonsense, there#s no real bug in dhelp. Please tell me the number of the
bug report.
APH> (a) it's got it's own document store, which
APH> isn't well debugged, and
What an argument against a file format :(! Are you kidding?
APH> (b) there is no way to flush/recreate it from
APH> scratch, and kill all the orphaned objects which inevitably accrue in
APH> your database.
Nonsense, read the f*cking manual page of dhelp_parse! But this option
should be used only but the admin, it#s not a option for postinst
(speed)!!!
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/?)
APH> > 2.) With your solution we will have a problem to move from
APH> > /usr/doc and /usr/share/doc, see (1).
APH> Good point but surmountable.
Not really.
APH> > 3.) Commercial programs my include docreg files under /opt, see (1).
APH> See (1) on how this isn't a problem at all.
Not true, because the company doesn#t know where the sysop will install
the program (for example /usr, /usr/local/, /opt, etc.)
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.
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.
APH> > 5.) If a package maintainer has to move a doc directory to another
APH> > directory he don#t need to change the docreg file! He moves only
APH> > the docreg file to the new location:
APH> Interesting, but of dubious value. Suddenly if a docreg file move,
APH> the hidden, implied object identifier is changed. This will be
Ok connections between translations won#t work. But this is not a real
problem. And as mentioned yesterday, there#re other cases where we will
have the same problems.
Maybe it#s not a good idea, to use the filename as identifier. Our old
solution (doc-base) hasn#t got this problem.
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.
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.
APH> > 6.) Upstream maintainers could deliver docreg files. It#s not a problem
APH> > to which location the distributors will move the documents.
APH> Interesting, but probably upstream maintainers would be more
APH> interested in adding the DC metadata fields to their HTML files rather
APH> than shipping debian-specific docreg files. As I said, one can
This is not our decision!
APH> trivially write an HTML/DC -> docreg file converter; but in your
APH> scheme this is a lot harder to do, i.e., in a pipeline.
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!
APH> > 7.) You can include docreg files to tar archives (they use relative
APH> > paths). Example: binary distributions, commercial software.
APH> Hmm, interesting. Both schemes allow this however. Remember, the
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!
For example you can install netscape to all directories you like. And this
will not work with your solution. This is a fact.
APH> relative URL in my scheme says: "the document area for the package
APH> <p>, plus the remaining path indicated."
I was talking about the position of the docreg file!
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: