Re: Re^2: Debian Metadata Proposal -- draft rev.1.4
Hello Marco and Adam.
Let me jump in.
On Mon, Jul 06, 1998 at 01:22:38AM -0400, Adam P. Harris wrote:
>
> It's true that I didn't raise the issue of using Dublin Core (DC)
> element set as our standard element set. But I wanted to work out
> what it would look like, so I started re-writing using DC and it
> worked out really well.
I agree.
> > And as a normal package developer I don#t want to read 38 kbytes just to
> > register one document.
>
> I'll take this under advisement. I've tried to organize the document
> such that stuff relevant for package maintainers is at the front.
> First is the intro, then the description of the elements, then the
> file format. How could I organize it better?
You don't need to organize it better. People will work from examples anyway.
I never really read the standard how to write a menu file. I just copied a
file from another packaged, chnaged it, and skimmed over the standard if
there are things I could add. Done.
> > *) install-docs script: calls the auto converter, dhelp, dwww, ...
>
> Validates the file before calling anything. Then will have a hook
> mechanism to invoke whatever systems are installed, i.e., dhelp.
Although I think the preferred way would be a database and an interface usd
by all frontends (we can postpone this discussion, though).
> > *) Markus directory structure as .dogrec.dir
>
> AFAIK, the ddh is a file containing the DDH entries, not a directory
> structure, but I might be confused. Marcus?
Yes. Actually, it is two things at the same time:
1) An abstract hierarchic tree.
2) Multiple files, written in a soon-to-be-defined standard that register
the tree in doc-base.
And it defines how to place documents in the tree.
> > 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?
>
> I could easily make it a tag which is ignored. I would like more
> opinions than just yours on this issue, however.
I like it, as I already pointed out. It gives an orthogonal characteristic
of the document.
Marco, I really hate the howto section in the DDH. I don't hate the idea to
access howtos in a single section, but I hate the orthogonality of DDH and
Document Type. I think the Type: field is the correct solution for this
problem. I hoped you would recognize this and would be happy that this is
adressed properly. In some way, it was requested by you.
> > For example this description of the content (howto, faq) is not necessary.
> > For this we will have our directory structure.
>
> The *type* of file (FAQ, dictionary file, home page, software package)
> and where it is located along the DDH tree are not coupled. For
> instance, we don't have debian/admin/faq, debian/admin/howto.
Yes. See above. I like this.
> > 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.
>
> I agree that LANG in Title and Description fields should *perhaps*
> simply reflect the underlying Language field of the document itself.
> I.e., a German document would carry a German Title and Description and
> that would be that. I think that might be a reasonable restriction to
> make at the outset. I'd like some opions from other International
> users before restricting functionality so radically, however.
Ah, sorry I misunderstood this the first time I read. Please ignore my prior
comments about this language dependency of title and description,, I was
confused.
I don't think it is worth the effort to treanslate a title and description
without a translation of the document.
> > or selfhtml
> Never heard of it. References?
It is a HTML tutorial in german language. I don't have it around, so I can't
check what it says about Dublin Core.
> Functional arguments please. What functionality is missing? What do
> you not like, aside from the rather *trivial* issues you've brought up
> (Type element and LANG scheme). Below you admit the functionality is
> there and only these minor issues raise your objections.
I don't think Type is trivial, btw. I think it is a *mayor* improvement,
because it allows flexible data access, much more flexible than implementing
howto and faq sections in the DDH.
> > 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.
>
> Why? I think knowing the freeness of a document before reading it is
> useful, it's in harmony with the Debian Tao, and I don't see you
> offering any arguments against this *optional* tag except that you
> don't see any reason for it. But again, the issue of whether the tag
> is optional or demoted to ignored is kinda a non-issue.
I too can't understand why Marco objects against an optional field. Marco,
you don't need to implement it in dhelp. What exactly is your technical
argument?
> > Marco> 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?
>
> No, it's not part of docreg, but it is part of the Debian Metadata
> spec.
>
> AFAIK, right now, there shall be one big file, in RFC822 format,
> defining the heirarchy.
Yes, we an produce one big file out of the several files I use for
development. It will be in RFC822 format, will use some tags of Dublin Core,
some tags of its own.
> > *) placement of the files (should be /usr/doc/<package>)
>
> Amenable to this if others agree.
I disagree. Spreading hidden files around /usr/doc and /usr/share/doc is
flawed and contradictionary to the unix way of doing this. Take a look at
the menu files, they are stored centralized as well.
One single directory for all doc-reg files is ideal. I can't see any benefit
of /usr/doc/* docreg files.
Minus:
1) Hidden files (dot-files), this shows that this is the wrong location for
them (you wouldn't expect them to be there).
2) What about files that don't refer to a file under /usr/doc, for example
links in the www? So we need a /usr/share/doc-base/whatever/docreg/
directory anyway. Why not stroing all files there, then?
3) Accessing a single directory is faster than accessing all directories in
/usr/doc. (Try "time ls /usr/doc/*/copyright" on your system.)
Marco, could you please summarize your technical objections agains a common
directory for all files?
> > *) URLs should be relative to the .docreg file
> > real internet URLs are allowed (to add for example the bug tracking
> > system)
>
> Reserved about this because its seems like bad system design; although
> as you point out it does solve the FHS vs FSSTD problem. I say its
> seems like bad system design because you are coupling the file system
> location with the resource identifier location. Converting in and out
> of docreg format would be difficult. Any storage system would need to
> track where it discovered the docreg file, for making absolute
> references out of relative ones.
I don't see any problems here. A relative URL should be checked against
file://localhost/usr/doc/ and file://localhost/usr/share/doc in the
transition period.
> None of these are deal-breakers.
>
> Finally, here's another problem with this scheme, a more serious one.
> Suppose package foobar, which is only FSSTD compliant, installs a
> docreg file in /usr/doc/foobar/foobar.docreg. Suppose that
> 'foobar.docreg' contains an entry for 'foobar.html' (relative, in your
> scheme). As I understand it, in your central document store, you
> would have an object (row) with an identifier of
> '/usr/doc/foobar/foobar.html'. Then suppose the next version of the
> pkg foobar is FHS compliant, but the maintainer forgets to run the
> removal process at the old location. Now, as I understand it, when
> the new pkg installs, we'll have another object (not replacing the
> original) with an identifier '/usr/share/doc/foobar/foobar.html'.
> How do we deal with this? Reap objects without files?
This sounds all very strange and way too complicated, if you ask me. We
should stick to Adams proposed solution.
> What's the solution?
Disallow relative URLs.
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: