Re: WebPlatform Browser Support Info

Actually, I do not think it should redirect to the specification or
whatever.
What should actually be there is the actual data (compatibility and
specification links) according to that filter. So, yes, a query string
could be more appropriate for that, but it also used as a namespace URI for
that matter, which is why a path based URL is better than a query string.

But I may have just gotten the wrong idea here.


☆*PhistucK*


On Sat, Oct 19, 2013 at 4:25 PM, Tobie Langel <tobie@w3.org> 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
> > >
> > > --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. For example, although UA strings are a
> meaningful identifier, they don't need to be tied to a URL.
> > 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)?
>
> --tobie
>
>