Re: WebPlatform Browser Support Info

On Sunday, October 20, 2013 at 7:02 AM, Doug Schepers wrote:
> Hi, folks–
>  
> On 10/19/13 9:25 AM, Tobie Langel wrote:
> > On Saturday, October 19, 2013 at 3:05 PM, Ronald Mansveld wrote:
> > > Tobie Langel schreef op 2013-10-19 14:54:
> > > > So what would these URLs actually point to?
> > > >  
> > > > My feeling is you don't really want to consider this info as a
> > > > data object in itself but as a filter, which is why I'd imagine
> > > > it much more in a query string then in the url itself. E.g.:
> > > > filtering the test results for test foobar:
> > > >  
> > > > …/tests/foobar?browser=chrome&device-manufacturer=samsung&device-family=galaxy&device-model=s3
>  
> Other than making the URL much longer, why do it that way?
>  
> Nothing about using URIs for identifiers, even if they serve as data  
> endpoints, precludes us from also providing a querystring filter.
>  
> > > > --tobie
> > > At this point I have made no assumptions on where those URL's link
> > > to, other then that those URL's will always reply with a 301 to a
> > > document with more information. Whether that is the w3c or
> > > whatwg-spec in case of features, a page on mobilehtml5.org (http://mobilehtml5.org)
> > > (http://mobilehtml5.org) that tells more about the device or
> > > browser, or some other page that explains what it is we're talking
> > > about remains to be decided.
> >  
> >  
> > Creating dummy URLs that don't point to meaningful data is as
> > meaningless as UUID and perhaps more confusing.
>  
> A UUID is completely opaque, and unrelated to the data it identifies. If  
> you look at a set of UUIDs, there's no consistent way to order or filter  
> them except by having a hardcoded list of those UUIDs and dereferencing  
> them. I'd much rather work with an identifier that I can eyeball.
>  
> I don't see how it would be confusing.
> > For example, although
> > UA strings are a meaningful identifier, they don't need to be tied to
> > a URL.
>  
> I thought we determined that UA strings aren't sufficiently unique or  
> consistent to serve as identifiers.
> > > However, because we use dedicated URL's on data.webplatform.org (http://data.webplatform.org)
> > > (http://data.webplatform.org), those URL's (and thus the
> > > identifier) can stay the same, while the redirect can change
> > > whenever needed, ie when a feature is moved from spec A to spec B.
> >  
> >  
> >  
> > That's a different issue altogether. Although I see the benefits of
> > this extra-level of indirection, I also see its downsides (much like
> > t.co (http://t.co) URLs have advantages--shortness--and disadvantages, you have no
> > idea what they point to).
> >  
> > Is the threat of moving references really that serious that we want
> > to cater for it? If so, wouldn't migrating the data be a good enough
> > solution?
> >  
> > Do we know for sure we will want to redirect the URLs in all cases
> > (e.g. a test run should point to the test that was actually run, not
> > its updated version)?
>  
>  
> I'm proposing URIs as identifiers, independent of whether they are also  
> URL endpoints. So, I'd prefer to defer the issue of what the URIs would  
> point to until later, in the interest of moving forward. I don't want to  
> get bogged down at this point, when we could always change the  
> identifier, or the redirection endpoint, to something else, if we wanted.
>  
> I'm hearing some support for using URIs as identifiers, but also some  
> objections. How can we resolve this quickly?

I've started opening issues against the spec in the form of a pull request with inline issues[1].

Ronald, please merge it so we have a basis for discussion.

I've more to add, I'll send another PR later.

--tobie

---
[1]: https://github.com/ronaldmansveld/webplatform-browser-compat/pull/1

Received on Sunday, 20 October 2013 10:10:35 UTC