Re: Editorial changes to clarify usage of URIs / Absolute URIs and @profile

Ivan Herman wrote:
> On Feb 8, 2011, at 17:34 , Nathan wrote:
> 
>> Ivan Herman wrote:
>>> The bottom line is: I am not convinced all this is necessary, except for some informative warning. I do not think there is any reason to disallow a profile URI of the form http://a.b.c/e#f. This is a perfectly correct URI that can be used for a HTTP GET. So why going out of our way to disallow it?
>> Indeed, a perfectly valid URI, and the frag will be dropped as part of the dereferencing process sometime before the GET happens / request is made.
>>
>>> There is a fact that is simply the consequence of HTTP. If we have two profile URI-s, namely http://a.b.c/e#f and http://a.b.c/e#g, then these two, while returning the same RDF graph serialized in some form when a GET is performed, ie, defining the same prefixes and terms (which is still fine!), may be considered as different for a caching mechanism, ie, it may be less efficient to handle them. This is not error, just an awkwardness for whoever used them....
>> Yup, every HTTP cache will not use the frag URI that's for sure, will/should be caching HTTP responses relating to requests, and will "see" both URIs as 'http://a.b.c/e' - I guess somebody may hard code the graph(s) as being associated with the frag URI(s), in which case yeah that could be a bit awkward for them and potentially lead to unexpected behaviour (say where the hard coded graphs is associated with /e and /e#f but not /e#g).
>>
>> I was just suggesting that we changed the value space of @profile to be absolute-URI, because then regardless of whether somebody wrote http://a.b.c/e or http://a.b.c/e#f or http://a.b.c/e#g in @profile, it would always be seen as http://a.b.c/e .
> 
> If we do that than an implementation may have the obligation to check, the URI may be defined as not comformant, we would have the obligation to decide what happens if that is the case (would we block processing for the whole subtree?), re-edit the document, etc., etc.,... I just do not feel all this is worth the trouble!

it would essentially just be "fragments in @profile are ignored" - but 
as I said I'm easy on it and don't think it'll be an issue often, if at 
all. We can ignore it, add some guidance, cater for it within the spec, 
or spec @profile such that it's not an issue for anybody implementing 
the spec even if authors add a fragment in there - 'sup to you, I was 
just responding with some approaches since you mentioned it :)

Best,

Nathan

Received on Tuesday, 8 February 2011 16:55:41 UTC