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

Re: Status bibref gatherer (Was: Tasks pages (close to) fixed; Bibref does not seem to be updated automatically)



Le Mon, Mar 12, 2012 at 05:11:00PM +0100, Andreas Tille a écrit :
> 
> I took the "Reference" field for granted because it was used heavily in
> practice.

Hi Andreas,

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

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 ?

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.

instead of currently:

  URL to an upstream page containing screenshots (not screenshots.debian.net).

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.

Another point that we should better rediscuss is whether we continue to
consider the keys (the field names) case-insensitively or not.

Have a nice week-end,

-- 
Charles


Reply to: