On Aug 2, 2011, at 8:19 PM, Markus KARG wrote:
>>
>> +1. Absolute as a default is obviously more interoperable (or portable,
>> to use your terminology).
>
> "Obvious"? Is it now commen sense that all what I propose has to be prooven, while all what some others say is "obvious"?
I can't resist to say that I also found the wording "obviously more interoperable" to be a bit strange in terms of reasoning :-)
Jan
> I mean, you demanded that I shall proof that pub/sub is not RESTful, while you now declare something to be "obvious" that not only was objected by me but at least two times by other experts like Jan? Did I miss something here? Have we different status or amount of votes in what is "obvious" and what has to be prooven?
>
> As long as one can enable relative mode, it plays no role whether it is more or less interoperable: It must work. If it does not, we must not provide that possibility at all. What shall it be good for to enable relative mode optionally if there are chances that clients cannot process it? So either we can safely use it as a default, or we can get rid of relative at all. I do not see a need for an option that bears the risk of breaking clients.
>
> And again, a client that is too dumb to resolve a relative link is by definition a broken one, regarding to the respective RFCs as mentioned by Jan.
>
>>> and back to your question,
>>> we don't know at the client side whether the relative links have been
>> created from the original base URI the client used or
>>> from the current URI, and 'should' is not a strong enough guarantee.
>> Saving payloads and restoring them afterwards may present
>>> another issue as far as the resolution is concerned.
>>
>> Can you provide an example. Seems I got lost again. Sorry :)
>
> Maybe we should start using moderated threads concentrating on one single proposal at one time. We all lose track too often. This is uneffective for all participants.
>
> Regards
> Markus
>