[AppStream] Adding another component specifier for variant

[Matthias Klumpp]

Am Mo., 23. Sept. 2019 um 18:44 Uhr schrieb Richard Hughes
<hughsient at gmail.com>:
>
> On Mon, 23 Sep 2019 at 15:42, Matthias Klumpp <matthias at tenstral.net> wrote:
> > > There are no such things as dumb questions, only lack of documentation :)
> > Hehe ^^ - There might have been documentation here that I didn't find ^^
>
> https://www.fwupd.org/lvfs/docs/metainfo is somewhat helpful
> explaining what bits of AppStream we use.

This is a fully valid metainfo file - with one exception:
The <requires/> tag has a firmware requirement, which the
specification currently doesn't permit:
```
<firmware compare="ge" version="0.1.2"/>
<firmware compare="ge" version="0.3.4">bootloader</firmware>
```
What does it mean if there is a firmware requirement tag with no value?
I think this should be in the spec as fwupd implements it, so maybe I
can add this to the next AppStream release already that is scheduled
to be done today.

> > When I hear "System Update", I immediately think it's an OS update,
> > not that firmware is updated (even though the operating system and
> > hardware system are both "systems" in a way). Was the name chosen
> > because the non-tech user doesn't know what "firmware" is, or does
> > this have some deeper roots?
>
> System is for the main board firmware, if it's just a random mouse or
> keyboard it would be "Device Update"

Slightly confusing, but "system" is such an insanely generic term,
that this makes sense. Thank you for clarifying!

> > So, I think I do understand the problem now, and I guess we can cover
> > this. Not sure if a "variant" toplevel tag is the best name, and how
> > this should actually be specified. I assume the "if there are multiple
> > components with the same name, the variant string should be appended
> > to the component's name in round brackets" may be the besr definition.
>
> Yes, this is fine.
>
> > Maybe a tag name like "flavor" would make sense here
>
> Hmm, I guess variant implies that one is more the "main model" and the
> other is a specialism of the generic component (which in my case might
> be true).

Technically, a "software variant" or "component variant" makes sense.
The reason why I am unusre about it is that I have a proposal for a
"variant" component property around that would specify the type of
e.g. an addon, so you would have `<component type="addon"
variant="visual"/>` or `<component type="addon"
variant="functional"/>` to separate between themes and functional
extensions. That idea isn't fully fleshed out yet (that's why I
haven't made an "official" attempt yet to add this feature), so we
should probably just ignore it.

Other words that come to mind are:
> <alternative>

Firefox is an alternative to Chrome, but yet they are completely
different products, so I think that's no a good choice.

> <choice>

Sort of implies that there are multiple and that the user can select
one, which isn't actually the case.

> <distinction>
> <option>
> <alternate>
> <adaptation>
> <choice>
> <variety>
> <subdivision>
> <strain>

I think either variety or subdividion make sense. When looking at
dictionaries and a thesaurus, it looks like "variety" isn't actually
what should be used here and "variant" is the actual noun that
describes variety as something diverging from the norm. A
"subdivision" implies some form of organizational structure to me,
which is also not what we actually want to say here.
I could throw "specialization" in the ring, as "China" is a
specialization of the generic firmware to work in a particular country
or with a particular device model.
Another option the thesaurus suggested as fitting what we mean well
would be "variation" - that is almost the same thing as a "variant" if
we want to save that word for later use.

What do you think about the last two suggestions? Tbh, I am quite a
bit more inclined to just use "variant" - while it sucks a bit to use
such a useful generic tag name, it isn't actually used in AppStream
yet, there is a useful proposal on the table to make use of it right
now and the term "variant" would clearly fit the intended purpose of
the tag very well, which is the most important thing.
Since this tag is translatbale, maybe using <variant_name/> is the
thing we want to do here. So the variant itself would be
machine-readable, but the name of the variant would be translatable.
One thing I like about the AppStream spec is that you can almost make
sentences out of the XML tree: "<component/> <provides/> a
type=flashed <firmware/>" for example, or "<component/> <name/>" is
Firefox. Having "<component/> <variant_name/> is 'China'" on en_US
would actually make sense in that context. And it would allow us to
have a <variant/> tag later in case we ever need a non-translatable
identifier for a specific software component variant that we can not
infer from the component-ID or other data.

What do you think? Sorry for the braindump-style of this mail. This
happens when I don't have a very clear preference apparently.
Cheers,
    Matthias



-- 
I welcome VSRE emails. See http://vsre.info/