[EMAIL PROTECTED] (Marco Budde) writes: > APH> suffix, because I might have little experimental docreg files lying > APH> about which were never meant to be a part of the document store (i.e., > APH> were never installed by a pkg). > > I assume that all .dhelp files in /usr/doc are registered.
And that all registered .dhelp files are in /usr/doc. Doesn't this break your promise that users can use the metadata system on their own, i.e., use it to maintain system wide documentation or web pointers? This breaks FHS. In my scheme, is doesn't matter a *whit* where the files are (i.e., the central store would probably have to remember where all the registered docreg files are for the reconstruct option). Remember, I'm quite flexible when it comes to stipulating where the "containers" (i.e., docreg files) are to be located. In fact, for some tricky httpd tricks, I could see how putting docreg files locally with the documentation would be a win. I.e., there could be a server hack where it is able to identify docreg files, and render directory listings in cute ways. Plus local use of metadata, which *has* to be under /usr/local according to the FHS. Furthermore, in my scheme, object identifiers are created from the Identifier element, period. That's the crucial difference. I'm beginning to thing the "central document store", for now, should just be a list of the registered docreg files, and a list of what identiers are found in which files. Perhaps later, when Marco etc. have implemented some web interfaces for it, we could take a fast-access system (if we need to for performance reasons) and fold that back into doc-base, if we all think it's appropriate. -- .....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
