Re: Status bibref gatherer (Was: Tasks pages (close to) fixed; Bibref does not seem to be updated automatically)
On Sat, Mar 17, 2012 at 12:18:06AM +0900, Charles Plessy wrote:
>
> "Reference" is not a field in the current specification. I think that this
> illustrates well the current confusion about the format. In that sense, it is
> not possible to answer to your question of what breaks by using nested mappings
> (YAML name for hashes) or sequences (YAML name for arrays), because their use
> is not defined. Therefore, from a formal point of view, nothing breaks. But
> also, nothing is guaranteed to work.
So we should go on with specifying it and I guess with this specification you
mean describing it at
http://wiki.debian.org/UpstreamMetadata
right? Or do you have other things in mind?
> It is good that you will gather other opinions Chemnitz. We can increase our
> use of mappings and sequences, but this will be at the expense of casual
> parsing in the same way as the Debian control files are parsed, that is,
> without simple tools such as sed, awk or grep when a simple information is to
> be retrieved. Features like tolerating and auto-detecting the replacement of a
> scalar by a mapping, as you proposed in the example of the Screenshots field,
> will make this simplest parsing more difficult. But if everybody is
> comfortable with this, why not ?
As far as I discussed the general advise was to adapt to the format
which was currently used by people who wrote such yaml files. So if the
Reference field is used as a hash currently and also arrays are used to
specify more than one reference there is no reason to restrict people
from doing so. On the contrary if we put restrictions upon the use it
might decrease the motivation to keep on creating such files.
> In that case, we need to write a proper documentation, and stick to it. To
> take again the example of screenshots, it would be:
>
> One or more URLs to upstream pages containing screenshots (not
> screenshots.debian.net), repesented by a scalar or a sequence of scalars.
Fully ACK.
> For the references, it would be:
>
> One or more bibliographic references, represented as a mapping or sequence of
> mappings containing the one or more of the following keys. The values for the
> keys are always scalars, and the keys that correspond to standard BibTeX entries
> must provide the same content.
I really like this.
> Another point that we should better rediscuss is whether we continue to
> consider the keys (the field names) case-insensitively or not.
I'm personally a friend of a spelling using a capital front letter
followed by small letters. However, the current use in existing
upstream files is a "random" capitalisation and the fact that at least
the use in BibTeX is also case insensitive we should probably agree to
continue to case-insensitive keys. I basically consider this an
esthetical problem because I can not imagine that we will bind different
meanings on different capitalisations. So I will not put my sense of
esthetics on anybody else.
Would you volunteer to put your proposed texts on the Wiki page and does
this in turn mean you are fine if I keep on working along the path I
started with the UDD gatherer, which means:
1. fetch upstream files from
svn://svn.debian.org/svn/collab-qa/packages-metadata
2. import into UDD using the code in
pre_udd_bibref/
as I commited to
git://git.debian.org/git/users/plessy/umegaya.git
?
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: