- From: Tobie Langel <tobie@w3.org>
- Date: Sun, 20 Oct 2013 12:11:44 +0200
- To: Doug Schepers <schepers@w3.org>
- Cc: Ronald Mansveld <ronald@ronaldmansveld.nl>, Niels Leenheer <info@html5test.com>, public-webplatform-tests@w3.org
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