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

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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>

Received on Wednesday, 24 March 2004 05:23:14 UTC