Re: [DEP 12] Why chosing YAML.
On Fri, 2013-01-25 at 11:46:14 -0800, Russ Allbery wrote:
> The difficulty with the deb822 format is that it doesn't have any concept
> of nested structure, so if you have a sequence of references and each of
> them has multiple key/value pairs, such as:
>
> "references": [
> { "author": "Name Surname", "url": "http://example.org/"; },
> { "author": "Other Name", "url": "http://example.edu/"; }
> ]
Ah, thanks Russ, should not have assumed the issue was that obvious
example I presented, sorry about that!
> Having done the latter previously in an LDAP schema (LDAP has a similar
> problem if one is trying to avoid subtrees), I would try very hard to
> avoid doing it ever again. You end up having to parse field names and
> extract numbers and then correlate stuff and it's just kind of a mess and
> very unsatisfying to work with.
Oh absolutely, precisely one of the reasons I didn't like the
Build-StageN fields on the first place.
> You can, of course, define an deb822 field value to have whatever
> structure you want (you could just have the value be JSON or YAML, for
> example), but that starts feeling kind of silly.
>
> I suppose another possibility is to define the deb822 field value as
> having as its contents a nested deb822 document and do something like:
>
> References:
> Author: Name Surname
> Url: http://example.org/
> .
> Author: Other Name
> Url: http://example.edu/
(Heh, my initial key-value example had more this shape than what I
ended up with.)
> Then it starts looking rather a lot like YAML.
Right, but with the difference that the same parser could be reused
for each nested contents w/o much more work, something that would not
be possible with YAML.
In any case, just let me make myself clear, I don't have anything
against YAML in itself, or I'm trying to present deb822 as a superior
format to YAML (the fact that YAML is human-friendly, yet it is
serializable by design is very nice). What I'm trying to say is that
(w/ enough effort, but not in a disproportionate way) mostly
anything we want to represent can be expressed in deb822, it might
just need some thought. In addition maybe this could serve to define
and extend deb822 to make it more structured, which would benefit
other usages.
Although the more I think about it, given the context, the more I get
the impression that this data might not belong in the package anyway,
because most of the things it describes are more or less independent
of the source package, and because having it somewhere else, where the
maintenance could be shared with other distributions beside Debian
would be really nice. The only drawback would be not having the
information self-contained in the package itself, but there's
precedent for that too, like debtags. But then it feels like I'm
starting to repeat myself, so I think I'll leave this here.
Thanks,
Guillem
Reply to: