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: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED] http://www.tu-harburg.de/~semb2204/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
