Re: Review of metadata 0.8.0
Yann Dirson <ydirson@mygale.org> writes:
> Here are my feelings about 0.8.0. As I did not follow previous
> discussions about this, some remarks may not be accurate, or some
> points may have already been discussed - you'll decide.
>
> * Allowing to set the LANG qualifier for the Description element would
> allow a non-native speaker of the document Language to decide whether
> it is worth trying to decipher it. As an example, myself fluently
> speaking french and english, but with only a rough understanding of
> german and some other languages, may, when confronted to some exotic
> doc that was not translated in any of my easy-understood languages,
> want to easily know if it is worth that I try to read this exotic doc.
I completely agree, although I wonder how many document maintainers
will actually take advantage of this. I guess I should turn it back
on; it doesn't really represent, in itself, too much complexity. I
might hold off for a round or so.
> * The Contributor element could further use RFC 822, by allowing the
> parenthezied syntax to precise the nature of the contribution. Eg:
> "John Doe <john@doe.org> (translation from jp)". Maybe a SCHEME
> for this sub-element could be specified, for now restricted to
> "translation[ from <LANG>]"
I don't know. Doesn't this actually break RFC 822? I.e., you can do
A. P. Harris <aph@debian.org>
or
aph@debian.org (A. P. Harris)
It certainly is off the track of the intent of qualifiers. A cleaner
way to do this would be a defined set of qualifiers, i.e.,
Contributor: John Doe <john@doe.org> (ROLE=translator)
or some such.... What it's translated *from* is already apparent from
the Relation.IsBasedOn element.
> * Relation.IsVersionOf is mentioned in sect. 4.2, but not in the list
> of elements.
Oopsie! This was an oversight; I didn't intent to include this
element.
> * Sect. 4.2.1 says "Whatever the file name, the names must be globally
> unique across all packages. Prefixing them with the package name helps
> ensure against collisions.". Does this only refers to files in
> /usr/share/doc-base/docreg/ ?
Yes.
> * It's nice to give the maintainers the liberty of placing docreg
> files where they want to, but this may be somewhat confusing to some
> users. IMHO it would be good to finally select a "standard place" for
> docreg files, when one will be accepted by most maintainers ...
I agree. I'm going to standardize on being contiguous with the
documents themselves. This will facilitate people looking at metadata
casually from the shell.
> Some issues that I would like to be addressed, that I did not see in
> 0.8.0:
>
> * A way of telling a translation may not be fully up-to-date. Maybe
> that could be handled by the ignored Coverage element ?
I think adding a qualifier to the Relation.* tags would be must better
way to do this. I've added a wishlist for this.
> Some typos:
All integrated, except:
> sect. 6.3, parag. 3: "following states" should be "following state
> changes" ?
No that's me getting it to line up. ;)
--
.....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: