Re: WebPlatform Browser Support Info

Tobie Langel schreef op 2013-10-18 11:27:
> On Friday, October 18, 2013 at 9:56 AM, Niels Leenheer wrote:
>> On Oct 18, 2013, at 12:23 AM, Tobie Langel <tobie@w3.org 
>> (mailto:tobie@w3.org)> wrote:
>>> We've been using spec URLs to link features to test cases so far 
>>> (e.g. the test for the XmlHttpRequest abort method[1] links to the 
>>> abort method of the XHR spec[2]) why not continue using that method?
>>> 
>>> Likewise, test cases could be identified by their URL.
>> I already have have a spec URL for each of my tests. So this would 
>> would work well for me. But how do we deal with changes to the specs? 
>> It is not uncommon for URLs to change too.
> 
> These section level URLs are usually kept rather consistent across
> spec revisions, so this really only becomes an issue when the tests
> are drifting out of sync with the spec, in which case you already have
> a bunch of other problems.

For tests the URL might be enough, but that does imply that test URL's 
cannot be changed by the testsource anymore. I'm not sure whether that 
is something you'd want to impose.
For features I don't think the spec-URL will be enough. Already there 
are examples of CSS-properties that appear in multiple specs (ie 
color-correction is in Color Correction Module, as well as in Color 
Module Level 3).

>>> Finally, I'm not sure I understand the benefit of identifying 
>>> browsers by UUID. (Aren't user agent strings good enough for that?) 
>>> For a coarser (and more useful) picture, won't version strings do?
>> 
>> Using the user agent string is not really useful. It is sometimes not 
>> specific enough, at other times far too specific and sometimes 
>> completely wrong.
> 
> I'm not advocating using UA strings to organize the results for
> display, but to uniquely identify the browser on which the test was
> run. This let's you then use a UA string parser of the desired
> coarseness to display results. If we don't want to store UA strings,
> we should agree on browser names rather than use UUID, in which case
> I'd strongly advocate relying on the the names used by Browser Scope's
> UA parser[1] which is fully open-sourced. Disclaimer, I co-lead the
> project.

UA-string might be good enough, especially when combined with a good 
parser that distils the UA-string to the level we want to use it. I'm 
willing to use the UA-string combined with UA-parser, however, I need to 
check whether the MIT-license is compatible with the CC-BY that's used 
by webplatform. I'm still not too much into all the legal stuff to know 
this from the top of my head ;)

> Overall, while I applaud this standardization effort, I feel like the
> proposition is over complex. I'd suggest deriving a standard notation
> from implementation requirements and with the goal of providing a
> nice, palatable API rather than by starting from standardization.

While I tried to keep the spec as simple and plain as possible, I do 
feel it is necessary to set at least some boundaries. After all, this is 
what is going to be used by several parties to exchange data. The 
starting-point was the email that Doug send out earlier this week (even 
though work has started before, after a F2F meeting last week), so it 
actually is build upon implementation requirements. All in all this is 
just an effort to get all parties on the same wavelength, so we can do a 
fairly easy data-exchange, as opposed to writing custom imports for each 
and every datasource ;)


Ronald

Received on Friday, 18 October 2013 10:49:17 UTC