Re^2: Debian Metadata Proposal -- draft rev.1.4
Am 02.07.98 schrieb apharris # burrito.onshore.com ...
Moin Adam!
APH> > Why have you changed the whole concept without asking the other
APH> > developers :((?
APH> What do you think the email was intended for?
I shows *your* totaly new idea of the file format. Where#re all the things
we have discussed two month ago? As maintainer of such a standard your job
is to collect the proposals and ideas of all members that are interested
in this topic.
And I really don#t understand why we need several month for such a small
file format. I can not see a big difference between your latest version
and the version I suggested several months ago.
APH> It's not set in stone. Not at all. I posted it here for comments. I
But there#re no real changes to your old version. I don#t have a problem
with the format itself, but with your way. Instead of wasting the time
writing such a big document we should work on the format itself.
And as a normal package developer I don#t want to read 38 kbytes just to
register one document.
APH> wanted to clearly state my position, which took a while. The last
Again, *your* position. But as a maintainer it#s not your job to show only
your position, but a mixture of the best ideas.
APH> > Arhhh. Could we please finish one thing before starting another? At
APH> > first we need a *file format*.
APH> I defined the file format.
:((( That is *your* proposal, but not *our* standard. I could release a
proposal too, but this wouldn#t help us. We need *one* standard. And we
have to discuss about it! And you have to include not only your solutions!
APH> > We don#t need that for dhelp. As I#ve said several times, dhelp will
APH> > parse the new file format itself.
APH> Excellent. I know that. I said for "backwards compat", i.e., for old
APH> versions of dhelp, or for dwww.
Ok, you can do that, but I think that#s a waste of time. If the user
installs the latest doc-base he can install the latest dhelp, too. If we
have *one* file format, I#ll remove .dhelp support from dhelp.
APH> > I#m not interested in such an API for dhelp, because I need a special
APH> > structure. And we had discussed this already: dhelp will read the
APH> > docreg files itself.
APH> I don't know whether I agree with this or not.
Ok, let me explain that: I#m sorting all entries in my database in a
special way. So I don#t need to read the whole database in memory. And I
don#t need all informations stored in the .docreg files, so I#ll not add
them to my database (in fact there will be several databases in dhelp
0.4.x).
doc-base should provide the following:
*) the auto converter
*) install-docs script: calls the auto converter, dhelp, dwww, ...
*) Markus directory structure as .dogrec.dir
APH> > A single person project :(?
APH> Aren't you contributing here and now?
Yes, but without any results. I don#t see any of my ideas in your latest
proposal.
APH> What exactly have I don't that you are complaining about Marco? Just
I don#t like your way to get a standard. And I don#t like to wait several
month for such a small file format :(. Once again, I#m interested in one
file format.
APH> these ultimately be specified as URNs and served off either the local
APH> machine or off a web server (i.e., out of the DDP web pages).
? I can#t see any problems with my idea, I#m using this method in dhelp
0.3.x and there#re no problems.
APH> > APH> Currently, the domain of allowable values is
APH> > APH>
APH> > APH> * howto
APH> > I don#t understand that. We don#t need that, because for this purpose
APH> > we have got the section tag.
APH> Not as I read the DDH. Anyhow, it's an optional field.
Sorry, but this is not the question. We don#t need this. So why should it
be part of the proposal?
APH> > APH> * Subject
APH> > Why have you changed the name of this tag?
APH> To comply with Dublin Core.
And why should we do that? We#re talking about a small and *local*
configuration file for Debian. Your proposal shows that Dublin Core is not
the right solution for our file format.
For example this description of the content (howto, faq) is not necessary.
For this we will have our directory structure. And for example
"Title: (LANG=de)" is maybe a good idea for the WWW and the big search
robots, but for use it#s useless.
APH> I'm willing to talk about the wisdom of
APH> using an industry standard or our own proprietary tag set, but I
Sorry, but Dublin Core is not a industry standard, it#s one idea for a
metadata format (see HTML 4 standard or selfhtml). You#ll not find a lot
of programms using Dublin Core at the moment.
APH> haven't seen a single good argument to use a proprietary tag set when
APH> perfectly good standards are available.
Because Dublin has got an other target?
APH> > APH> * Rights
APH> > Do we need this tag?
APH> Again, it's optional.
That#s not the question. If it#s optional in Dublin Core we could drop it
from our proposal.
APH> > Not necessary, the title should be in the language of the document.
APH> !! Duh! That's a good point! I guess you're right that there's no
APH> point on translating the title of an english document into German, is
APH> there?
Right.
APH> Sure, you've said it many times, but you never convinced anyone else
APH> that it was a good idea. I'll review your arguemnt in the mailing
APH> list and try to address you points, it seems that this is the only
APH> major sticking point you have.
Right, I#ll really don#t like your solution. If you propose something like
Dublin Core, you should think a little big greater. Why should we limit
the use of our file format and our programms only to the Debian packages?
It#s also interesting for maintaining the local documents of the user.
APH> If I recall, you would prefer to have docreg files in the
APH> documentation area, i.e., /usr/doc/<pkg>. I am amenable to this,
APH> actually, but if you're going to be reading docreg files directly, I
APH> think this is going to be evil.
I don#t understand that. Do you think that speed is a problem? It#s not.
I#m using this in dhelp without any problems.
APH> One thing I want you to keep in mind that hamm's /usr/doc/<pkg> will
APH> be slink's /usr/share/doc/<pkg>, AFAIK.
This is not a problem with my solution. But it could be a problem with
your solution. A lot of users will install slink and hamm packages on one
system.
Then we#ve to add /usr/share/doc *and* /usr/doc to our webstandard in the
policy. But with your solution (storing the .docreg files in /var/...) you
will have a problem: how will you distinguish if your path is relative to
/usr/doc or /usr/doc/share?
APH> Docreg files should not need
APH> editing to deal with this.
This is not problem with both solutions.
APH> Personally, there's an easy way to resolve this. Someone needs to
APH> study URN spec more, and we must do what it will take to transition to
APH> URN or use URN right from the start. Any system which will make it
APH> *harder* to move to URN is unwise, IMHO.
What does URN mean? Could you please explain this?
APH> (b) any scheme *must* allow us to serve documents off other servers,
APH> i.e., debian DDP web area
I don#t understand that, too. Do you mean that we need relative paths and
URLs? That#s right. But I don#t see the differences between both
solutions.
APH> (b) all identifiers for documents *should* allow us to transition to a
APH> URN scheme very easily, if not use that from the get-go
Again, what does you mean with URN?
APH> > 2.) Why should we store one information twice?
APH> I'm willing to dump the document store concept entirely if you, as the
APH> dhelp maintainer, thinks it's not going to be useful. Hey, it just
APH> makes my life easier!
Maybe other programms would like to use it. I don#t know.
APH> > I#m missing the tags for adding new sections and their description.
APH> Yes, that's not part of the docreg spec per se. The DDH is a "SCHEME"
But it should be part of docreg. Maybe it#s a good idea to seperate the
documents and the directories: for example .docreg and .dogreg.dir?
APH> Marco is working on this.
Me :)? You#re speaking about Markus, right? He#s working on the "directory
informations" but we need a file format to add this informations to the
databases of dhelp, doc-base, etc. And this is very important.
APH> I'll probably help him with the definition
APH> of the file format. It's pretty straight forward, it's not in a
APH> standard format because there *are* no such standards AFAIK, and it
APH> hasn't changed much.
Again, we need an open discussion about such things. And not only the
result of one person at the end.
APH> I hope we can work out our differences, Marco. Although, frankly, if
I hope this too.
APH> substantive critiques in your email. The only critique of the format
APH> as I see it is the placement of files, and the scheme we use to refer
APH> to resources.
That#s right, this is my main problem with your proposal. And I don#t like
the new things like (LANG=...) and the content description (howto, faq, ).
The format itself is ok (in fact I don#t see any big differences to
.dhelp).
APH> Why do you not like the docreg format?
*) placement of the files (should be /usr/doc/<package>)
*) URLs should be relative to the .docreg file
real internet URLs are allowed (to add for example the bug tracking
system)
*) not necessary elements from dublin core: (LANG=..), content
(FAQ, HOWTO, I#ve forgoten the name of the tag) should be removed
*) how to add new directories
APH> Why do you object to using a leading industry standard, which has
APH> covers *each* of our requirements?
If cover all requirements, we could use the standard, no question.
APH> What features or tags do you need that are not there?
That#s not a problem. I think we should remove some tags. But this is not
a real problem, because dhelp could ignore them.
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: