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:19:29 UTC