[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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>
  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

> * 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/ ?


> * 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: