Re: Issue 455 closed: Representation header and SOAP processing model

This was discussed before PR, it was envisaged that @relay would be a 
URI, but this was dismissed because we wanted the spec out.

This would have to be raised as a Spec issue against Part 1.

JJ.

Pete Hendry wrote:

> Could @relay be changed to an enumeration of "always", "never", 
> "processed", etc. Is there a finite set of values it could take to 
> convey the intention of @relay and @sticky? This could remove the need 
> for 2 attributes related to relaying the header.
> 
> Pete
> 
> Jean-Jacques Moreau wrote:
> 
>>
>> Hum... it's not my recollection and I don't see this in the minutes[1] 
>> either. Did I miss something obvious?
>>
>> If we were indeed to use @relay="true", there would be no need for a 
>> special role, and we could simply use "next", as was suggested 
>> initially by Noah.
>>
>> In addition, as Hervé reminded us recently, @relay only helps when a 
>> header block was understood but NOT processed. @relay does not help 
>> when the header block was indeed processed. This is where we need the 
>> additional semantics provided by "sticky" (or whatever it ends up 
>> being called), i.e. always reinsert even if processed.
>>
>> Actually, it now really looks to me like we are augmenting our 
>> processing model with this new role. I don't think it's Representation 
>> header specific; hence I prefer the name "sticky" to 
>> "reinsertRepresentation". Simply "reinsert" would be ok.
>>
>> Obviously, my closing email was so confusing that it generated a lot 
>> of extra discussion. Apologies for not having been clear enough.
>>
>> I'll be attending tonight's telcon.
>>
>> JJ.
>>
>> [1] <http://www.w3.org/2004/03/02-xmlprotocol-irc.txt>
>>
>> Anish Karmarkar wrote:
>>
>>>
>>> The resolution IIRC wasn't quite that.
>>> It wasn't 'always reinserted'. It was --
>>>
>>> Define a new role (name to be decided) that causes a Representation 
>>> header block targeted to it be reinserted if processed.
>>>
>>> (removed the always).
>>> It is always reinserted only if relay is also true.
>>>
>>> -Anish
>>> -- 
>>>
>>> Jean-Jacques Moreau wrote:
>>>
>>>>
>>>> What about the following amendment to your point 1?
>>>>
>>>> <amendment>
>>>> Define a new role (name to be decided) that causes any 
>>>> Representation header block targeted to it to always be reinserted, 
>>>> even if processed.
>>>> </amendment>
>>>>
>>>> Jacek Kopecky wrote:
>>>>
>>>>> Oh, I think your closing email [1] is a bit wrong and a bit confusing:
>>>>>
>>>>> it says the five numbered points are characteristics of the new role,
>>>>> where only the second is, in fact. The first point isn't true (IIRC),
>>>>> the use of the new role is totally up to the application; a
>>>>> Representation header can be targeted at any other role and the usual
>>>>> rules apply, including the points 3a, 3b and 4 in the closing email.
>>>>>
>>>>> I think the closing email should be rephrased to something like:
>>>>>
>>>>>
>>>>>         At its recent f2f, the XMLP WG decided to close this issue 
>>>>> with
>>>>>         the following actions:
>>>>>                 1. define a new role (name to be decided) that 
>>>>> causes all
>>>>>         Representation header blocks targeted to it always to be
>>>>>         reinserted, even if processed.
>>>>>                 2. Note that it's OK for multiple Representation 
>>>>> header blocks
>>>>>         in the same message to have the same URI and role. Such
>>>>>         Representation header blocks would typically have different
>>>>>         metadata.
>>>>>                 3. Note that implementations MAY need to process 
>>>>> Representation
>>>>>         header blocks BEFORE other header blocks that might 
>>>>> dereference
>>>>>         URIs.
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>>                    Jacek Kopecky
>>>>>
>>>>>                    Systinet Corporation
>>>>>                    http://www.systinet.com/
>>>>>
>>>>>
>>>>> [1] 
>>>>> http://lists.w3.org/Archives/Public/xmlp-comments/2004Mar/0024.html
>>>>>
>>>>>
>>>>> On Mon, 2004-03-22 at 16:56, Jean-Jacques Moreau wrote:
>>>>>
>>>>>> Yes it does! The (agreed) resolution says: "Define a new role as 
>>>>>> above [plus other stuff]".
>>>>>>
>>>>>> "Above" says: "Proposal (again): Define a new role. 
>>>>>> Characteristics of this role are; 1. if you process a Rep header 
>>>>>> targetted at this role, you MUST resinsert it."
>>>>>>
>>>>>> If point 1. was not to be taken into consideration, why would the 
>>>>>> agreed resolution say "as above"? My reading is that the scribe 
>>>>>> figured out it could save some typing, instead of reinserting 
>>>>>> (again) the whole proposal once more.
>>>>>>
>>>>>> You seem to be thinking otherwise.
>>>>>>
>>>>>> JJ.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>