Re: WebPlatform Browser Support Info

Regarding the idea of using specifications URLs as identifier for features,
yes, they usually remain consistent. But (especially in the CSS 3 and later
kind of specifications), features sometimes jiggle between specifications,
specifications converge or divide, or a feature is defined in multiple
levels (each has different semantics or definition).
I guess we should also have mapping for this jiggling as well, so even
though two sources use two different specification URLs for the same
feature, the raw data will list only one - the most current one.


☆*PhistucK*


On Sat, Oct 19, 2013 at 10:28 AM, Tobie Langel <tobie@w3.org> wrote:

> On Oct 19, 2013, at 6:41, Niels Leenheer <info@html5test.com> wrote:
>
> >
> > On Oct 18, 2013, at 3:05 PM, Tobie Langel <tobie@w3.org> wrote:
> >
> >> On Friday, October 18, 2013 at 1:47 PM, HTML5test wrote:
> >>>
> >>> Using the UA-string as an identifier for data exchange is also not
> very useful I think.
> >>>
> >>> The results I collect are not limited to a specific browser or UA
> string. For example one test result could say: this result is valid for
> Firefox 20 on desktop. There is not one UA-string for this result. There
> are maybe a couple of dozen.
> >> I'd argue that this is an interpretation of the result, not the result
> itself.
> >
> > Fine, call it an interpretation. That is not the point.
>
> My intent wasn't to be dismissive. Sorry!
>
> I think there are multiple parts to this issue:
>
> 1) the tests themselves,
> 2) a test run: which is the result of running the test on a particular
> user agent (and which creates a relationship between a UA string and a test
> result).
> 3) turning a UA string into a meaningful browser and version name (best
> done by a tool such as ua-parser which is open-source and language
> agnostic).
> 4) the knowledge of how to group the different browser versions together
> do that the output is meaningful for developers. This is both slightly
> subjective and subject to change. This is the part I suggested was
> interpretative. That's also where a lot of the value lies. It would be
> great if we could express this either as an algorithm on top of ua-parser
> or just spec it rather than embed it in the raw data. That would let us use
> it for all data sets, not just yours and would allow us to quickly and
> continuously adapt to browser changes.
>
> > The data I have can not be expressed as a result for a single UA string.
> And I am pretty sure this does not apply to just my data.
>
> The raw data you had a some point can. My point is that this is the data
> we should be working with as the interpretative layer on top of it changes.
>  (you might no longer have that data, but that's a different problem).
>
> > If we are going to share data using a common format, we need a format
> that can actually describe the data we have.
>
> Well, ideally, yes. However, it is possible, though unlikely, that there
> is no commonality between the different data sets or that the common
> denominator doesn't let us do what we want with the data.
>
> --tobie
>
>
>