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

A couple of comments:

1) I agree completely that relay is only for unprocessed headers, and I 
think we should keep it that way.

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

2) I really, really do not want to change the core SOAP model in a 
discussion of a single Representation header.  This is not a role that is 
automatically to be understood by all SOAP processors:  it is a role that 
helps the specification of a particular header (in this case 
representation) fulfill the responsibility of that specification to 
determine whether the header is reinserted if processed.


I think we have two choices, either of which I could live with.

I.  A role, probably in a namespace associated with the representation 
header and named something like "reinsertRepresentation".  The spec for 
the representation header would say "if the role is 
reinsertRepresentation", than reinsert.

-or-

II. A specification for a role (something we haven't had before) named 
"resinsertHeader".  The specification for that role would say 
"specifications for particular SOAP headers (modules using headers) MAY be 
written to indicate that when the header is targeted to this role and 
processed, a header identical to that processed MUST be reinserted at the 
same position in the relayed message". 

I think II. is what you're asking for, but not implemented as a change to 
the core SOAP model.   It's something we allow particular headers to buy 
into.  I feel we had the opportunity to do it in the SOAP model when we 
wrote SOAP 1.2 and we declined to do it.  I feel quite strongly that we 
should not, perhaps cannot, change the core responsibilities of all SOAP 
processors without a republication of the SOAP rec.  By requiring the spec 
for reinsert to be referenced by the spec for each header, we bring into 
play mechanisms like mustUnderstand, and we also preserve compatibility 
for those headers that may have already been created with other specs that 
mandate removal regardless of role.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>
03/24/04 04:56 AM

 
        To:     Anish Karmarkar <Anish.Karmarkar@oracle.com>
        cc:     Jacek Kopecky <jacek.kopecky@systinet.com>, Noah Mendelsohn 
<noah_mendelsohn@us.ibm.com>, XMLP Dist App <xml-dist-app@w3.org>
        Subject:        Re: Issue 455 closed: Representation header and SOAP    processing model


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 11:38:00 UTC