Re: Re^8: Debian Metadata Proposal -- draft rev.1.4
Marco.Budde@hqsys.antar.com (Marco Budde) writes:
> Am 18.07.98 schrieb apharris # burrito.onshore.com ...
> APH> > We need it for the translated or auto-converted documents.
> APH> Why? Translations are translation of files. Their identifier is
> APH> their file path.
>
> No, as I#ve showed we need a "real" ID. With you solution you can#t move a
> original to another directory or change the filename without breaking all
> translation and auto-converted links to the original. This is a bad
> design.
I disagree with your conclusion.
> And it#s not possible to add one URL several times. This could be a real
> problem with http:// links.
Sure it is, if you want that. We could just allow the Identifier to
repeat, or the Relation.IsBasedOn to repeat.
> With my solution the ID is unique and the directory/filename could be
> changed. So please change the draft of our standard, we should have
>
> Identifier: <package> <could be choosen by the maintainer>
> File: <path, should be relative to the docreg file>
I disagree with this. If you want persistent resource identifiers,
we've got to go with a URN/URL scheme. Notating *persisten*
identifiers in docreg files (containers for metadata) is not
acceptable and would indeed be very poor design.
Identifiers do not identify the metadata but they identify the
resource. Do you understand this distinction? Furthermore, a single
resource may have multiple metadata entities referring to them. Do
you start to see why your scheme is impractical? In your scheme, the
metadata entity is the one constructing the actual resource
identifiers, as well as the mapping from resource-ids to pathnames.
This is not an appropriate job for a metadata entity to do, since a
resource-id is in fact residing with or without a metadata entity.
Furthermore, several metadata entities might ascribe new resource-ids
to the same file name! How are we supposed to manage resource-ids and
how they map to file names in this scheme?
If you really want persistent identifiers for resources, you have to
manage them out of the metadata... I suggest you start hacking on the
URN2URL stuff ASAP then. It's up to you.
> APH> I haven't seen a single reason why I need globally unique metadata
> APH> entity identifiers. Lets move forward on implementation and see if we
> APH> do or not. I hope not.
>
> That#s not possible. I need the final design, before I change dhelp. I had
> changed the database and the parser, but than you#ve changed the draft and
> I don#t have the time to rewrite it several times.
You arguments are weak and do not compel me. Give me better arguments
and we shall all discuss it.
> So please add it to the draft, because I need it for dhelp. And please add
> the tags for Markus# directory structure.
Yes that will be coming in soon.
> And again, we#ve to talk about the location of the docreg files and the
> path (relative,absolute).
Have you read the spec v0.8.0? I comprimised and included both your
and my and Marcus' scheme.
--
.....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: