Hi,
See intermixed....
Konrad Lanz escribiÃ³:
> should be treated by: ' or ".." ' --> append "/.."
>> But there are only two ways of obtaining the output:
>> "then append ".." or "/.." for the latter case respectively to the
>> output buffer".
>> By reading this I do not know what I have to add to the output buffer
>> in case 1. (out buffer is empty).
> append ".." (because ' "/.." for the latter case respectively ' should
> be applied for the last case only)
>
I still think that the text is at least subject to missinterpretations,
as the existence of only two cases, empty buffer or buffer equals to
"../" being one and buffer equals to ".." being the other, is not
completely clear from the text... I would suggest to reword it to reduce
risks of missinterpretations.
>
> Please note Action-49
> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0028.html:
>
>> //s/remove the last segment and its preceding "/" (if any) from the
>> output buffer/remove the last segment and its preceding "/" (if any)
>> from the output buffer and if hereby the first character in the
>> outputbuffer was removed and it was not the root slash then delete a
>> leading slash from the input buffer///
>
I see. Konrad, I plan to check all the examples that you provide in the
annex.Then I take the annex that you circulated, make this text
substitution, apply the algorithm to the examples and let you know...
Regards
Juan Carlos.
> I tried to stay as close as possible to the original text, but maybe a
> complete rewording might simplify the processing.
>
> Eg. : Loosely speaking something like:
> Complete ".." path segments eat the previous segment, iff it is not a
> ".." segment by itself. Complete ".." segments accumulate to the left
> if the URI reference is relative and no path segments to be eaten
> appear, if however the URI is absolute complete ".." segments
> disappear when they hit the root slash ...
>
> and so on ... treating "//", ".", "/./" and so forth
>
> regards
> Konrad
>