[EMAIL PROTECTED] (Marco Budde) writes: > As I read > the Dublin Core Homepage Dublin Core will never be a standard. The team is > working on RDF (XML based), see www.w3.org.
Marco, yet another unsubstantiated claim. Sure, they'er working on RDF; that's a major reason why I chose them. I suggested in Feb to use XML as the transmission format and was shouted down. It doesn't matter; the format impedence is minor compared to the element impedence. In other words, RDF will have rocking back-support for Dublin Core, whenever it comes out (late fall?) > MB> I don't think Type is trivial, btw. I think it is a *mayor* improvement, > MB> because it allows flexible data access, much more flexible than > MB> implementing howto and faq sections in the DDH. > > And how would you describe all other documents with type? Using type will > produce a lot of work for the package maintainers without any improvements > for the users. Unsubstantiated. It's an optional element. How can an optional element create work for package maintainers, please explain? > MB> I too can't understand why Marco objects against an optional field. Marco, > MB> you don't need to implement it in dhelp. What exactly is your technical > MB> argument? > > That#s right, I#ll not use it. An argument is space on the local disc. Why > should we add the same information several times to the hard disc? I think > we should make docreg as simple as possible. This will help the > maintainers understanding our standard. Putting the same info, shadowed in multiple places, is exactly what dhelp does. I propose to eliminate that and adopt a central document store, rather than having display systems read docreg files. APH> > APH> * Rights APH> > We don#t need that -> <foo>/copyright. APH> That's true, we don't *need* it; it's optional. OTOH, for APH> instance on a DDP site or whatnot, knowing the rights would be a APH> good thing. > But how should Rights work? Should the maintainer add the copyright > text ifself? Read the spec. > MB> One single directory for all doc-reg files is ideal. I can't see any > > No, as I#ve showed several times, one directory has got a lot of > disadvantages. Marcus and I have raised a number of what I would consider crippling objections to your proposed relative identifier scheme. I haven't seen you address one of those objections yet. The only real objection you've raised concerning my URL/URN scheme is the not insurmountable FHS vs FSSTD issue. So where's the beef? > MB> So we need a /usr/share/doc-base/whatever/docreg/ > MB> directory anyway. Why not stroing all files there, then? > > We don#t need it. How will you enable the functionality of recreating a document store (i.e., the database in dhelp) from scratch? I submit this is a crucial requirement for debugging, and dhelp contains a number of critical bugs because (a) it's got it's own document store, which isn't well debugged, and (b) there is no way to flush/recreate it from scratch, and kill all the orphaned objects which inevitably accrue in your database. > 1.) With your solution you can only support one subdir (/usr/doc). > But we should offer support for every location (for example > /usr/local/doc). Untrue. Absolute URLs, including file://localhost/usr/local/doc/foobar/ are allowable. > 2.) With your solution we will have a problem to move from > /usr/doc and /usr/share/doc, see (1). Good point but surmountable. > 3.) Commercial programs my include docreg files under /opt, see (1). See (1) on how this isn't a problem at all. > 4.) Relative links are always better, html itself uses in most cases > relative links! Or read the link chapter in the policy. We propose to resolve relative links against a "path" of /usr/share/doc:/usr/doc:http://www.debian.org/doc . Your system doesn't allow this at all. > 5.) If a package maintainer has to move a doc directory to another > directory he don#t need to change the docreg file! He moves only > the docreg file to the new location: > > /usr/doc/<foo>/ -> /usr/doc/<foo>/html > > He has only to change one line in rules: > > cp docreg usr/doc/<foo> > > to > > cp docreg usr/doc/<foo>/html Interesting, but of dubious value. Suddenly if a docreg file move, the hidden, implied object identifier is changed. This will be confusing for maintainers and difficult to support, and will lead to a greater number of orphaned objects in your database. Why should file position determine the object identifier? I think most people will find this suprising, opaque, and confusing. > 6.) Upstream maintainers could deliver docreg files. It#s not a problem > to which location the distributors will move the documents. Interesting, but probably upstream maintainers would be more interested in adding the DC metadata fields to their HTML files rather than shipping debian-specific docreg files. As I said, one can trivially write an HTML/DC -> docreg file converter; but in your scheme this is a lot harder to do, i.e., in a pipeline. > 7.) You can include docreg files to tar archives (they use relative > paths). Example: binary distributions, commercial software. Hmm, interesting. Both schemes allow this however. Remember, the relative URL in my scheme says: "the document area for the package <p>, plus the remaining path indicated." > MB> I don't see any problems here. A relative URL should be checked against > MB> file://localhost/usr/doc/ and file://localhost/usr/share/doc in the > MB> transition period. > > Speed :). Premature optimization is the root of all evil in programming. -- Donald Knuth, paraphrase -- .....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
