W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2004

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

From: Jacek Kopecky <jacek.kopecky@systinet.com>
Date: Tue, 23 Mar 2004 15:25:01 +0100
To: Noah Mendelsohn <noah_mendelsohn@us.ibm.com>
Cc: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>, XMLP Dist App <xml-dist-app@w3.org>
Message-Id: <1080051901.1967.23.camel@localhost>

Noah, 

I like the direction of the first suggestion, but I would note that in
absence of other features saying otherwise, SOAP Processing Model
mandates that the header is removed by forwarding intermediaries. Your
text seems to imply the nodes may freely choose otherwise, without
reference to active intermediaries which is what those nodes would
become.

Jacek

On Mon, 2004-03-22 at 17:30, noah_mendelsohn@us.ibm.com wrote:
> I still think it would be useful to give some guidance on what the 
> reinsertion rules are if you don't use the new role.  I read the original 
> proposed text as saying "reinsert if processed regardless of role" which 
> (a) isn't what I remembered us deciding and (b) seems to make the 
> introduction of the new role at best redundant.  I think I would consider 
> one of the following two rules for re-insertion after processing if the 
> role is not "sticky":  Either:
> 
> I.  Except in the specific case of role="sticky", this specification does 
> not mandate whether or a node processing a Representation header should or 
> should not reinsert a similar header targeted at the same role.  Other 
> specifications, such as the specifications for additional headers, MAY be 
> used in conjunction with specification to mandate either the reinsertion 
> or reliable removal of processed representation header.  Accordingly, 
> absent the use of such additional features, applications should not depend 
> on the presence of such reinserted representation headers.
> 
> -or-
> 
> II.  Except when role="sticky", processing of a Representation header MUST 
> NOT cause (I.e. does not implicitly cause) reinsertion of a similar 
> Representation header targeted to the same role.  Note, however, that the 
> action of other processed SOAP features MAY cause similar or identical 
> Representation headers to be (re)inserted. 
> 
> I think I can live with either of these, probably slight preference for I. 
> except that it might be viewed as too subtle and thus confusing.  I think 
> the behavior is similar in practice.   In other respects, I think I agree 
> with Jacek's formulation.  Thank you.
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> Jacek Kopecky <jacek.kopecky@systinet.com>
> 03/22/2004 11:17 AM
> 
>  
>         To:     Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
>         cc:     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
> 
> 
> 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 Tuesday, 23 March 2004 09:25:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:16 GMT