Re: WebPlatform Browser Support Info

Hey, folks–

First: excellent first draft, Ronald! Thanks!!


It seems to me that how we store the data in JSON and how we expose it 
in the API can be quite different. The API can provide a user-friendly 
abstraction layer.

I do like the idea of using "meaningful" (descriptive) UUIDs, possibly 
expressed as URLs, because I think that would help with debugging and 
making sure you're requesting and getting the right data. And we could 
even expose those URLs as data endpoints, if we found that useful.

So, as an example:

For "FeatureCategory", instead of:

{
   "uuid":"456789AB-CDEF-0123-4567-89ABCDEF0123",
   "name":"CSS"
}

... it could be something like:

{
   "uuid":"http://data.webplatform.org/FeatureCategory/CSS/",
   "name":"CSS"
}

URLs can still be unique, especially if we concatenate:

{
   "uuid":"http://data.webplatform.org/browser/ie/9/windows",
   "browser":"Internet Explorer",
   "vendor":"Microsoft",
   "version":"9",
   "os":"windows",
}

... or:

{
   "uuid":"http://data.webplatform.org/browser/chrome/30.0.1599.69/osx",
   "browser":"Chrome",
   "vendor":"Google",
   "version":"30.0.1599.69",
   "os":"osx",
}

Those URLS are longer than the UUIDs you proposed, but they are human 
readable, unique, rather intuitive, and flexible.


I agree with the earlier point about separating out prefixes from 
vendors, and vendors from browser names. Prefixes are not unique to a 
vendor (both Apple and Google, and many others, used "-webkit"), nor 
does one vendor only use one. It's better tied to the test or test result.

I'm not yet convinced about Tobie's point on the complexity; we should 
certainly strive for as much simplicity as possible, but we shouldn't 
oversimplify for either interchange or storage. It will be easier to 
trim back than to add new layers.


Regards-
-Doug

On 10/19/13 12:41 AM, Niels Leenheer 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.
>
> 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. If
> we are going to share data using a common format, we need a format
> that can actually describe the data we have.
>
> Niels html5test.com
>

Received on Saturday, 19 October 2013 05:50:16 UTC