Yann Dirson <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> (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 <[EMAIL PROTECTED]> or [EMAIL PROTECTED] (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 <[EMAIL PROTECTED]> (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. [EMAIL PROTECTED]<URL:http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
