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: [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]
