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 [EMAIL PROTECTED] for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
