Re: WebPlatform Browser Support Info

On Saturday, October 19, 2013 at 7:50 AM, Doug Schepers wrote:
> Hey, folks–
>  
> First: excellent first draft, Ronald! Thanks!!
Is it on github somewhere that we can fork it? That would be really useful.
> 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.

Agreed.
> 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.

+1 (nitpick: you can no longer call these UUIDs).
> 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"
> }

I really like how this is shaping up and how we're linking the difference resources (testthewebforward.org, w3.org/tr/, webplatform.org, html5test.com, etc.) together in this API.
> 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.

We're starting to see a structure for identifiers emerge here:

test cases: url to test case (on GH repo?),
browsers: UA string?
test runs (aka test results): tbd. Is a UID necessary, here? Or is just the combination of a test case URL and UA string:

{
    "test-case": "https://github.com/w3c/web-platform-tests/blob/master/XMLHttpRequest/abort-during-done.htm",
    "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36"
    "results": {
        "video.canPlayType() - codecs parameter order": "pass",
        // ...
    }
}

category: url on webplatform.org
browser "groups": this needs more discussion. Doug's proposal above goes in the right direction but I'm not sold on it yet.
> 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.

prefixes are tied to test runs (relationship between a UA and a test case.
> 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.

I think we're in agreement though we're not expressing it the same way. There are two notions here:

1. simplicity, which here is about focusing on defining the primitive data types and expressing the relationships between them and nothing more. This is where I find relying on UUID over-engineered for now.

2. raw data persistence, which I think is what you're referring to and which is equally important: making sure that we store all the low-level information we need so we can combine them in new and interesting ways in the future as new requirements come up. For example, if we store tests runs with UA strings rather than with the output of a given ua-parser, it'll be a lot easier for a third party to couple our data set with their logs, statcounter.com or what not.

--tobie

Received on Saturday, 19 October 2013 09:14:20 UTC