Re: WebPlatform Browser Support Info

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) 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), 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 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?


Regards-
-Doug

Received on Sunday, 20 October 2013 05:02:58 UTC