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

Re: [DEP 12] Why chosing YAML.



Guillem Jover <guillem@debian.org> writes:
> On Sat, 2013-01-05 at 17:09:10 +0100, Andreas Tille wrote:

>> If you check out the Wiki for the Reference field you see that it is
>> defined as a mapping or sequence of mappings.  I have no idea how to
>> express this in deb822 format and I could perfectly think of similar
>> data to store in debian/upstream of this kind.  So I'd regard deb822
>> simply insufficient for storing what we want to store and so the
>> question whether to use deb822 for debian/upstream becomes void.

> I can think of several ways, one coulf be by defining that the contents
> of a Reference field are key value pairs, as in:

> Reference:
>  author Name Surname
>  url http://example.org

> or variations on this, with or w/o the :, etc, with the subfield
> capitalized, etc. This has the very obvious drawback that you need parse
> the contents explicitly, outside the normal parser. Although, the more
> natural way to represent those in deb822 format is:

> Ref-Author: Name Surname
> Ref-Url: http://example.org

> or variations like expanding the field names to stuff like Reference-Url.

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/"; }
]

(in JSON), there's no way to "natively" represent that structure without
resorting to mingling different types of metadata together in the field
name and doing things like:

    Ref1-Author: Name Surname
    Ref1-Url: http://example.org/
    Ref2-Author: Other Name
    Ref2-Url: http://example.edu/

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.

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/

Then it starts looking rather a lot like YAML.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: