[AppStream] Putting review data into AppStream

[Matthias Klumpp]

2016-07-19 14:07 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
> On 19 July 2016 at 12:46, Matthias Klumpp <matthias at tenstral.net> wrote:
>>> * To curate a set of verified reviews we can use offline for RHEL.
>> That's a weird usecase, but on a second thought it does make some
>> sense (why does this need to be offline though?).
>
> Well, a lot of RHEL desktops don't have internet, and might only be
> able to install applications mirrored on some kind of internal server.
> Random apps parsing evil markup from random web services would
> probably give the security team heartburn.

Okay - I will add a new thread for curation information to this list,
which will deal with adding such data in a different way than merging
components in weird ways (but that's for the new thread).

>>> <reviews>
>>>   <review karma="35" date="2016-07-01" rating_percent="80">
>> Makes sense - we need to describe what karma is and what we expect the
>> frontend to do with it.
>
> I've defined karma as an signed integer that corresponds to how useful
> other people found the review. Positive values = useful review,
> negative = not useful.

Is there an upper (or lower) limit? Past which value is the review "useful"?

>>>     <lang>en_GB</lang>
>>
>> <lang/> is in line with the rest of the spec, but.... Tood bad we
>> didn't go with <locale/> :P
>
> I did wonder about if we wanted to support translations of reviews,
> i.e. <description xml:lang="pt_BR"> - it also would mean we don't need
> to have the standalone <lang> tag that is normally used in
> <languages>.

IMHO that wouldn't make too much sense, especially since we can just
add the same review translated to a different language...
So, a <lang/> or <language/> tag makes sense to me here. (complex
translation logic is also not useful in a web-server context, where I
guess we just request the reviews for a specific language anyway)

>>>     <version>0.1.2</version>
>>>     <display_name>Richard Hughes</display_name>
>>
>> Make that "reviewer_name" maybe, and allow a "reviewer_id" to uniquely
>> identify individual reviewers?
>
> reviewer_name makes sense to me, but i do think the ID probably
> belongs as an attribute of the review itself; it's going to be a hash
> or integer and isn't going to be ever extended, so something like this
> might work better:
>
> <reviews>
>   <review id="3045" karma="35" date="2016-07-01" rating_percent="80">

This would make it a review-id, not a reviewer-id. This looks like a
unique identifier for the particular review, rather than one for the
particular reviewer.

>     <summary xml:lang="en_GB">Looks great!</summary>
>     <description xml:lang="en_GB"><p>Long description with
> markup</p></description>
>     <version>0.1.2</version>
>     <reviewer_name>Richard Hughes</reviewer_name>
>   </review>
> </reviews>
>
> I rejected using <id> for the review ID as everywhere else this refers
> to an appstream-id, e.g. "gimp.desktop". One other nice change might
> to to use <name> rather than <reviewer_name> although I wonder if that
> overloads things in the way I've just tried to avoid.

I agree on all points - there is no place in the spec yet where an
"id" is not an AppStream Component-ID, so this doesn't feel right...

So, something like this maybe?

<reviews>
  <review karma="35" date="2016-07-01" rating_percent="80" xml:lang="en_GB">
    <summary>Looks great!</summary>
    <description>
      <p>
        Long description with markup
      </p>
    </description>
    <version>0.1.2</version>
    <reviewer_name>Richard Hughes</reviewer_name>
    <reviewer_id>3045</reviewer_id>
  </review>
</reviews>

Cheers,
    Matthias

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