Re: Should specifications take sides in the httpRange-14 debate?

Looks like the frag id syntax is being repurposed  to fit yet another requirement.  http-range14++
All the best, Ashok

On 11/20/2012 11:49 PM, Larry Masinter wrote:
>
> Speaking for myself:
>
> I think the TAG taking up this issue was based on the presumption (which I question) that httpRange-14 was an issue that made sense without any additional context, or that, even if the question made sense, that a uniform answer was necessary or feasible.
>
> if I working group wishes to promote one side or another, let them. There is no reason to imagine the TAG would make more progress in the next 10 years than it has in the last, on this (so-called) issue.
>
> The design proposed is one where there is a WebID protocol element whose value resembles a URL (not a URI? Surely you are not planning on requiring the non-English world to use ASCII WebIDs?) but is not in fact _/any/_ URL but rather a string which meets other criteria but also uses the http or https scheme with a fragment identifier. Presumably you will outlaw http://localhost/ or http: URIs which don't include FQDNs (fully qualified domain names), etc.
>
> Given that you have a string resembling a URL but not really 'any URL', any decision made in such a narrow application is unlikely to be accepted by "other sides" of identifier preferences.
>
> Larry
>
> --
>
> http://larry.masinter.net
>
> *From:*Stéphane Corlosquet [mailto:scorlosquet@gmail.com]
> *Sent:* Tuesday, November 20, 2012 9:09 PM
> *To:* www-tag@w3.org
> *Cc:* Tim Berners-Lee
> *Subject:* Should specifications take sides in the httpRange-14 debate?
>
> Several members of the WebID CG met last month at TPAC, and one major outcome backed by timbl was to standardize WebID on hash URIs because they are easier to implement/deploy compared to 303s. Quoting from the new spec [1]:
>
>     A WebID is a URI with an HTTP or HTTPS scheme, containing a URI fragment identifier (i.e. a # symbol) and which uniquely denotes an Agent (Person, Organisation, Group, Device, etc.). The URI without the fragment identifier denotes the WebID Profile page.
>
> This decision made a few members of the group uncomfortable including myself [2-4] and generated a lot of discussion on the mailing list. I wasn't at TPAC to hear Tim's arguments, but I got to meet him today and asked about his reasoning. Note that I've never been against hash URIs, and I agree that they make sense for WebID (and many other scenarios). I use them myself. What makes me and others uncomfortable is to see a spec taking sides in the httpRange-14 debate by mandating one approach, when this debate is still on-going and some people are working on a possible new resolution. Should specifications relying on HTTP URIs take sides and pick a "winner" in the httpRange-14 debate? I would much rather see these specifications refer to the appropriate standard for publishing non-information resources on the Web. I know we don't have such standard today (at least one that people are happy with), and that's part of the problem. I see at least a couple of risks for a specs 
> like WebID to set in stone a specific kind of URI. First, it means that whichever new resolution that comes out of the debate might make the existing WebIDs obsolete.. Secondly, having deployment of one kind of URI might influence the TAG towards choosing the most deployed method to avoid any disruptive resolution, when a disruptive resolution is maybe what is needed.
>
> If Tim fells strongly about hash URIs based on the experience of several members of the community who got burnt with deploying 303 redirects, I'd like to ask that such recommendation be formalized at a higher level than each individual spec, so that groups writing specs such as WebID don't have to go through the same permathread over and over. How close are we with regards to a potential resolution of httpRange-14? What needs to happen to reach such resolution? What do you recommend us to do in the meantime? Are there precedents where specifications mandated a type of URI deployment? If the TAG isn't willing to find a resolution, is there any Working Group which might be interested in pursuing this goal? LDP?
>
> -- 
> Steph.
>
> [1] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
>
> [2] http://lists.w3.org/Archives/Public/public-webid/2012Nov/0135.html
>
> [3] http://lists.w3.org/Archives/Public/public-webid/2012Nov/0142.html
>
> [4] http://lists.w3.org/Archives/Public/public-webid/2012Nov/0137.html
>