[AppStream] A dedicated format for AppStream metadata curation and augmentation

[Matthias Klumpp]

2016-07-22 12:56 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
> On 22 July 2016 at 11:05, Matthias Klumpp <matthias at tenstral.net> wrote:
>> So, IMO we need a dedicated XML format to ship generic curation data.
>> This is what I have in mind right now:
>> <curation origin="Debian">
>>   // origins could also be "GNOME-Software" or "AppRecommender", etc.
>
> I think merging extra data into components is more general than just
> curation. I think we want to consider:
>
>  * Replacing data with higher-priority data
>  * Appending data only when it doesn't already exist

Agreed - my previous approach was, as you know, the one you outline
below, but the the AppRecommender usecase appeared, which called for a
different solution and I wasn't sure whether tackling this with a
dedicated augmentation format makes sense.

> I think both things could be achieved with:
>
> <component type="merge" priority="1">
>
> where priority is optional.
>
>>   <featured environment="gnome">
>>     <id>org.gnome.Totem</id>
>>     <id>org.gnome.Documents</id>
>>     ...
>>   </featured>
>
> Featured in what way? Featured as a banner on the overview, in the
> popular lists, or in the category lists? All? I think all of these are
> separate problems.

Jup, and some which might make sense to tackle in the SC directly.

>>   <styles>
>>     <banner>
>>       <id>org.gnome.builder</id>
>>       <url>https://git.gnome.org/browse/gnome-software/plain/data/featured-builder.png</url>
>>     </banner>
>
> Do we specify a size or aspect for this banner? Are appstores going to
> agree? Do the designers want KDE apps to use oxygen on GNOME? Does a
> specific banner make sense on mobile too? Does the banner have
> user-translatable text?
>
> I think there are some good ideas here, a merge component would make
> appstream-glib much cleaner, and it would be good to standardize how
> to pick favorites in the specific ways but I think we need much more
> discussion before anything is decided.

Yes - as you know, my idea for this was calling the component type
"partial", but I think now that "merge" is actually not a bad name.
So, I added this to the TODO list and we will likely have it in the
next version of the spec - highly likely together with the <suggests/>
tag.
I will hurry up to have this in Git so there is something you can
comment on, to see if there is anything missing and that we agree on
the same tag name.

Cheers,
    Matthias


-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/