Re: includePathStartsWith and initial /

Hmmm... I see.

This suggests we amend the canonicalisation steps so that missing out 
the leading / becomes important (we currently say that if it's not there 
in the value of pathStartsWith then the processor should add it in).

An alternative might be to add a new property that dealt with URI 
schemes where the assumptions made in the canonicalisation are not safe, 
i.e. a 'Do not canonicalise' flag. Would that make you throw your hands 
up in horror? I can see that it's another operational ease/semantic 
formality clash.

An alternative would be to define a set of additional properties like 
includeHostNC, pathStartsWithNC etc. that would again switch off 
canonicalisation.

Incidentally, we have an outstanding comment from Thomas Roessler that 
we haven't attended to yet on the issue of canonicalisation [1] so the 
whole thing is up for re-trial.

[1] http://lists.w3.org/Archives/Public/public-powderwg/2007Nov/0012.html


Jeremy Carroll wrote:
> 
> 
> I suggest that the examples and text should unify round the initial / 
> being included in an includePathStartsWith
> 
> I believe that in a URI like
> 
> mailto:jeremy.carroll@hp.com
> 
> that the path is jeremy.carroll@hp.com
> 
> so that
> 
> <wdr:includePathStartsWith>jeremy</wdr:includePathStartsWith>
> 
> matches this URI, but, in my book (but not the current WDs) not
> 
> http://example.org/jeremy
> 
> for which the path is /jeremy
> 
> 
> jeremy (or /jeremy)
> 
> 
> 

Received on Friday, 21 December 2007 11:57:27 UTC