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

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 Monday, 22 March 2004 11:32:25 UTC