[go: up one dir, main page]

Re: Issue 455 closed (again): Representation header and SOAP processing model

This resolution is acceptable to me, BUT particularly given the comment 
about reference by other specifications, I would suggest that we restate 
the resolution text to make clear whether the attribute is namespace 
qualified, and if so by what namespace.  I believe the answer is "not 
qualified", implying that if another spec were to refer to our attribute 
it would do so for purposes of comparison, not for direct use (at least 
insofar as one tends to view unqual. attributes as scoped to the 
declaration of the element on which they appear.)  Thank you.

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








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

 
        To:     xmlp-comments@w3.org
        cc:     Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, Herve Ruellan 
<herve.ruellan@crf.canon.fr>
        Subject:        Issue 455 closed (again): Representation header and SOAP processing model


Dear Noah,

At its weekly telcon last week, the XMLP WG has decided to reopen issue 
#455, and to close it with the following resolution (the previous 
resolution was abandonned).

<newResolution>
The Representation header block carries a new attribute called 
@reinsert, whose type is "xsd:boolean", and whose value governs how the 
header block is reinserted. When the header block HAS BEEN processed, 
AND the value of the attribute is "true", the header block MUST be 
reinserted. (Note: this does not change the SOAP processing model, which 
explictely allows header block specifications to indicate whether they 
should be reinserted or not.)

In all other cases, and in particular when the value of the @reinsert 
attribute is "false", the normal rules of the SOAP processing model 
apply. In effect, a value of "false" produces a behaviour equivalent to 
NOT having the attribute at all.
</newResolution>

I think we also reached the compromise that, even though we will not 
generalize the @reinsert attribute, we will NOT preclude other 
specifications from referring to it. Unfortunately, I cannot find this 
in the minutes.

Please let us know immediately if you disagree with this resolution.

Jean-Jacques.

> Dear Noah,
> 
> You raised issue #455 about the interaction between the SOAP processing 
> model and the Representation Header.
> 
> At its recent f2f, the XMLP WG decided to close[1] this issue by 
> defining a new role (name to be decided), with the following 
> characteristics:
> 
> 1. The role will be used to target all Representation header blocks.
> 
> 2. The Representation header block MUST always be reinserted, even if 
> processed.
> 
> 3a. It's OK for multiple Representation header blocks in the same 
> message to have the same URI and role.
> 
> 3b. Such Representation header blocks would typically have different 
> metadata.
> 
> 4. Implementations MAY need to process Representation header blocks 
> BEFORE other header blocks that might dereference URIs.
> 
> Please let us know immediately if you do not agree with this resolution.
> 
> Regards,
> 
> Jean-Jacques.
> 
> [1] <http://www.w3.org/2004/03/02-xmlprotocol-irc.txt>

Received on Wednesday, 31 March 2004 09:26:58 UTC