Re: Re^4: Debian Metadata Proposal -- draft rev.1.4
Marco.Budde@hqsys.antar.com (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. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: