Re: WebPlatform Browser Support Info

On Friday, October 18, 2013 at 12:48 PM, Ronald Mansveld wrote:
> 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) 
> > > (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.

Cool URIs don't change. ;)
> 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).

That's a bug with the spec where true. FWIW I can't find color-correction in CSS 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 ;)

Should this be a concern, it is easy enough to fix. Legal should not be a burden here but a guarantee that the work we do can be disseminated in the intended way.
> > 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 ;)

That's understandable. If you only care for a data interchange format and aren't planning to use this for the end API, why don't you pick a format that already exists (e.g. TAP, EARL, etc.). On the other hand, if you're planning to use that format for the end API, please reconsider. UUIDs are an implementation detail and make people's eye sore. :)

--tobie

Received on Friday, 18 October 2013 11:02:10 UTC