Re: Re^4: Debian Metadata Proposal -- draft rev.1.4
Marco.Budde@hqsys.antar.com (Marco Budde) writes:
> Well, I#m not 100% sure, because our project and DCs have got a little bit
> difference goals and needs. For example using the file name as identifier
> is never a good idea. And this is a real problem in the WWW at the moment.
> It#s only possible to add links to URLs but not to a document (like the
> ISDN number).
Not true at all. I think you mean ISBN; and yes, DC can use ISBN as
Identifiers.
> APH> format. Did you look at the included example or not? For one, the
> APH> tag set changed, although there's a one-to-one correspondance. For
>
> That is not true. You (or the DC team) have merged DocumentID and File.
> And this produces new problems. I think the old solution was a lot of
> better.
Well, metadata needs to point to the resource it describes. There's
no way around that. There is no requirement that the Identifier
element be used as a unique objectID for the metadata itself. So lets
try not to confuse the issues (although I often do too!)
> APH> I'll take this under advisement. I've tried to organize the document
> APH> such that stuff relevant for package maintainers is at the front.
> APH> First is the intro, then the description of the elements, then the
> APH> file format. How could I organize it better?
>
> Remove all SCHEME and LANG descriptions.
Hmm. This is probably a good idea.
> Keep it short. Is really
> difficult to read something like a description in the 822 RFC format.
> These formats are nice for programmers, but not for maintainers.
Hmm, you are probably right; I should fold off a separate chapter for
metadata implementors. Maybe even a separate manual.
> I don#t have got problems with other suggestions. But I think that
> there#re a lot of bad solutions. For example some standard of the W3 (like
> CSS2) are not really good.
Agreed. The best example of overcomplex W3 standards I think is DOM.
> APH> > *) install-docs script: calls the auto converter, dhelp, dwww, ...
> APH> Validates the file before calling anything. Then will have a hook
> APH> mechanism to invoke whatever systems are installed, i.e., dhelp.
>
> It shouldn#t validate the files. This reduces speed. We should (your doc-
> base) offer a small Perl script, that checks the files from debian/rules.
Interesting idea. I've already pretty much decided we'll need a
doc-base and a doc-base-dev packages.
> APH> seems like bad system design because you are coupling the file system
> APH> location with the resource identifier location. Converting in and out
>
> Yes, but this is not a problem of my solution itself. This problem is
> introduced by merging docid and file. But which your solution we will have
> the same problems.
>
> If I (as package maintainer) would for example move HOWTO/ to HOWTO/html
> all links to the HOWTOs will be broken with both solutions.
Maybe our validator routine for pkg maintainers could check for this
case.
You're right that using file names in Identifier is problematic, but
it's unavoidable. The old doc-reg did the same, although it *also*
added an additional object ID (DocumentID) which was supposed to be
globally unique.
To be honest, I think the whole issue of slapping persistant, globally
unique identifiers on the metadata themselves is not a requirement of
the system. Why do we need to be have a objectID on a bit of
metadata? If a display system needs one, it could generate it on it's
own, i.e., a random number.
By conflating the pointer the metadata has to it's resource with an
"ID" for the metadata itself, we've dug ourselves into a conundrum.
--
.....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: