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

I believe this is in-line with historic and common usage, it's just 
<http://example.org/document#thing>, certainly no special requirements 
are added, beyond the potential advice to authors use URIs with a #frag 
rather than URIs which 303 within their RDF.

Best, Nathan

Ashok Malhotra wrote:
> 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
>>
>

Received on Thursday, 22 November 2012 10:19:51 UTC