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

Now I am getting really confused!

I agree with your 3 points. Point 1), i.e. first snippet says (amongst 
other things):

<logQuote>
if you process a Rep header targetted at this role, you MUST resinsert it.
</logQuote>

which I converted into:

<resolutionQuote>
The Representation header block MUST always be reinserted, even if
processed.
</resolutionQuote>

How is this different? What am I missing?

JJ.

Jacek Kopecky wrote:

> Jean-Jacques, 
> 
> I read the log as:
> 
> 1) we decide what the new role will look like (first snippet)
> 2) we add clarifications about multiple Representation headers (second
> snippet) 
> 3) we resolve issue 455 by defining the role (as above in 1), adding the
> two statements (in 2) and a further statement on ordering.
> 
> That's the full resolution. The rule about mandatory reinsertion of
> Representation was discussed before but dismissed in favor of the new
> role.
> 
> 's how I see it. 8-)
> 
>                    Jacek Kopecky
> 
>                    Systinet Corporation
>                    http://www.systinet.com/
> 
> 
> 
> 
> On Mon, 2004-03-22 at 16:26, Jean-Jacques Moreau wrote:
> 
>>Jacek, I think you may have missed an important expression in the 
>>resolution, "as above". To me, this was a reference to the initial 
>>proposal ("proposal again"), and meant that rule *2 was accepted. In any 
>>case, I don't see any trace in the log that indicates that it was 
>>abandonned.
>>
>>I tried to be quite carefull when sending the closing email, following 
>>the log quite precisely. But I may have missed anything obvious.
>>
>>What do you think?
>>
>>JJ.
>>
>>Jacek Kopecky wrote:
>>
>>
>>>Oh, in my recollection the rule *2. below was discussed as one of the
>>>approaches and dismissed in favor of the sticky role. Therefore the
>>>closing email [1] seems to be wrong.
>>>
>>>The IRC log seems to support me in this (I don't think I'm posting any
>>>member-confidential info here):
>>>
>>>
>>>08:38:59 <scribe> 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.
>>>..
>>>08:42:55 <scribe> Noah: We should say that it's OK for two
>>>Representation headers in a message to have the same URI and role
>>>08:43:34 <scribe> Noah: I'd rather add a note saying that such headers
>>>would typically have different media types
>>>08:43:50 <scribe> s/media types/metadata
>>>08:44:34 <noah> s/metadata/metadata such as media type/ :-)
>>>..
>>>08:50:54 <scribe> Proposal for resolving 455: Define a new role as
>>>above. Add the two statements above concerning two representation
>>>headers and the note about metadata. Add text stating that
>>>implementations might need to process Rep headers before other headers
>>>that might deref URIs
>>>08:51:59 <scribe> Issue resolved with above resolution without objection
>>>
>>>
>>>Jacek
>>>
>>>On Fri, 2004-03-19 at 17:39, noah_mendelsohn@us.ibm.com wrote:
>>>
>>>
>>>>Jackek Kopecky writes:
>>>>
>>>>
>>>>
>>>>>it seems to me that what you are describing is the
>>>>>default behavior - Representation header is removed by
>>>>>any node that processes it, except when the node knows
>>>>>better, e.g. by following the rules of our sticky role.
>>>>
>>>>Were that true we wouldn't be having this discussion.  Jean-Jacques 
>>>>proposal says [1] 
>>>>
>>>>* 2. The Representation header block MUST always be reinserted, even if 
>>>>processed.
>>>>
>>>>Maybe I'm misunderstanding, but this seems to eliminate all latitude, and 
>>>>perhaps make the sticky role somewhat redundant.  This discussion is 
>>>>starting to feel a bit strange, which is often a signal that I am 
>>>>confused.  If so, my apologies for leading us astray.
>>>>
>>>>Noah
>>>>
>>>>[1] http://lists.w3.org/Archives/Public/xmlp-comments/2004Mar/0024.html
>>>>
>>>>--------------------------------------
>>>>Noah Mendelsohn 
>>>>IBM Corporation
>>>>One Rogers Street
>>>>Cambridge, MA 02142
>>>>1-617-693-4036
>>>>--------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>

Received on Monday, 22 March 2004 10:42:50 UTC