W3C home > Mailing lists > Public > www-archive@w3.org > September 2002

Re: Issue 221 resolution text change

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Fri, 06 Sep 2002 17:28:47 +0200
Message-ID: <3D78C9AF.9050002@crf.canon.fr>
To: Marc Hadley <marc.hadley@sun.com>
CC: Martin Gudgin <mgudgin@microsoft.com>, noah_mendelsohn@us.ibm.com, W3C Archive <www-archive@w3.org>

Yes, I guess there is a subtle difference. I still find it 
bizarre, though, that an intermediary must not insert a PI but 
may relay one. This seems a little inconsistent to me.

Jean-Jacques.

Marc Hadley wrote:
> I agree that its busted, I wasn't championing a particular approach just 
> trying to make sure the paragraph captured the (admittedly awkward) 
> resolution of the WG in a crisp nailed down manner.
> 
> FWIW, I don't think the new text says "you can use PIs if you want to". 
> It says message content originators MUST NOT use PIs but intermediaries 
> don't have to check for them if they can't be bothered. There's a 
> difference I think.
> 
> Marc.
> 
> On Friday, Sep 6, 2002, at 04:37 US/Eastern, Martin Gudgin wrote:
> 
>> JJM,
>>
>> This is exactly the point I was making when I initially questioned the
>> resolution. But I decided that seen as the 'obvious' fix was not on the
>> table, I could ( just about ) live with Noah's formulation.
>>
>> I still think its busted really.
>>
>> Gudge
>>
>>> -----Original Message-----
>>> From: Jean-Jacques Moreau [mailto:moreau@crf.canon.fr]
>>> Sent: 06 September 2002 09:24
>>> To: Marc Hadley
>>> Cc: noah_mendelsohn@us.ibm.com; Martin Gudgin; W3C Archive
>>> Subject: Re: Issue 221 resolution text change
>>>
>>>
>>> I'm sorry to spoil the agreement, but I find the paragraph
>>> really, really bizarre. First, we say MUST NOT, which to me
>>> implies never, never send a PI. But then we add: well, take it
>>> easy, we're not really serious, you can use PIs if you really
>>> want to. Am I getting something wrong? Is a MUST NOT really not
>>> that strong? Have we not created an untestable assertion (MUST
>>> NOT/MAY)?
>>>
>>> Also, I think one of the initial use cases was that of an initial
>>> sender forwarding XML data, which could contain PIs, and over
>>> which the sender had no control. Are we not considering this use
>>> case any longer? Did I miss something?
>>>
>>> I'm easy about PIs; but I tend to find it difficult for the spec
>>> to remain undecided.
>>>
>>> Jean-Jacques.
>>>
>>> Marc Hadley wrote:
>>>
>>>> OK, how about the following:
>>>>
>>>> "SOAP messages sent by initial SOAP senders MUST NOT contain
>>>> processing instruction information items. SOAP
>>>
>>> intermediaries MUST NOT
>>>
>>>> insert processing instruction information items in SOAP
>>>
>>> messages they
>>>
>>>> relay. SOAP receivers receiving a SOAP message containing a
>>>
>>> processing
>>>
>>>> instruction information item SHOULD generate a SOAP fault with the
>>>> Value of Code set to "env:Sender". However, in the case where
>>>> performance considerations make it impractical for an
>>>
>>> intermediary to
>>>
>>>> detect processing instruction information items in a message to be
>>>> relayed, such intermediaries MAY leave the processing instruction
>>>> information items unchanged in the relayed message."
>>>>
>>>> Does that nail it ?
>>>>
>>>> Marc.
>>>>
>>>>>
>>>> On Thursday, Sep 5, 2002, at 12:39 US/Eastern,
>>>> noah_mendelsohn@us.ibm.com wrote:
>>>>
>>>>> I think this is generally good, but I'm uncomfortable with
>>>>
>>> the change
>>>
>>>>> to initial SOAP sender.  An intermediary can wind up
>>>>
>>> sending PI's in
>>>
>>>>> at least two ways, potentially:
>>>>>
>>>>> * In relayed content, for which we've agreed to allow wiggle room
>>>>> * In newly inserted headers, for which we allow no such lattitude.
>>>>>
>>>>> I therefore think that we need to go back to something like:
>>>>>
>>>>> Except in the special case of content relayed by
>>>>
>>> intermediaries (see
>>>
>>>>> below), SOAP messages sent by SOAP senders MUST NOT contain
>>>>> processing instruction information items.
>>>>>
>>>>> ...or some such.  If one wanted to be even more explicit,
>>>>
>>> at the risk
>>>
>>>>> of being verbose, one could also go with:
>>>>>
>>>>> "However, in the case where performance considerations make it
>>>>> impractical
>>>>> for an
>>>>> intermediary to detect processing instruction information
>>>>
>>> items in a
>>>
>>>>> message to be relayed, such intermediaries MAY leave the processing
>>>>> instruction information items unchanged in the relayed
>>>>
>>> message.   SOAP
>>>
>>>>> intemediaries
>>>>> MUST NOT include PIs in headers inserted by the intermediary."
>>>>>
>>>>> So, I really want to make it clear that there's no wiggle room for
>>>>> allowing PI's in new content by any sender, otherwise the
>>>>
>>> whole change
>>>
>>>>> we've just made is a waste of time.   Otherwise, I like
>>>>
>>> what you've done,
>>>
>>>>> and would be happy with any reasonable variation that
>>>>
>>> deals with the
>>>
>>>>> remaining concern.  Many thanks.
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> Noah Mendelsohn                              Voice: 1-617-693-4036
>>>>> IBM Corporation                                Fax: 1-617-693-8676
>>>>> One Rogers Street
>>>>> Cambridge, MA 02142
>>>>> ------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Marc Hadley <marc.hadley@sun.com>
>>>>> 09/05/2002 10:02 AM
>>>>>
>>>>>
>>>>>         To:     noah_mendelsohn@us.ibm.com
>>>>>         cc:     Martin Gudgin <mgudgin@microsoft.com>,
>>>>
>>> Jean-Jacques
>>>
>>>>> Moreau
>>>>> <moreau@crf.canon.fr>, W3C Archive <www-archive@w3.org>
>>>>>         Subject:        Issue 221 resolution text change
>>>>>
>>>>>
>>>>> Noah,
>>>>>
>>>>> I have incorporated the resolution to issue 221. In doing
>>>>
>>> so I have
>>>
>>>>> modified your proposed text as follows:
>>>>>
>>>>> Original:
>>>>> "Except in the special case of intermediaries (see below),
>>>>
>>> envelopes
>>>
>>>>> transmitted by SOAP senders MUST NOT contain PIs.
>>>>>
>>>>> Receivers (including intermediaries)  receiving an
>>>>
>>> envelope with a PI
>>>
>>>>> SHOULD fault with a XXXX fault.  However, in the case where
>>>>> performance considerations make it impractical for an
>>>>
>>> intermediary to
>>>
>>>>> detect PIs in a message to be relayed, such intermediaries
>>>>
>>> MAY leave
>>>
>>>>> the PIs unchanged in
>>>>> the relayed message."
>>>>>
>>>>> New:
>>>>> "SOAP messages sent by initial SOAP senders MUST NOT contain
>>>>> processing instruction information items. SOAP receivers
>>>>
>>> receiving a
>>>
>>>>> SOAP message containing a processing instruction information item
>>>>> SHOULD generate a SOAP fault with the Value of Code set to
>>>>> "env:Sender". However, in the case where performance
>>>>
>>> considerations
>>>
>>>>> make it impractical for an intermediary to detect processing
>>>>> instruction information items in a message to be relayed, such
>>>>> intermediaries MAY leave the processing instruction
>>>>
>>> information items
>>>
>>>>> unchanged in the relayed message."
>>>>>
>>>>> The main changes were associated with use of terminology
>>>>
>>> from section
>>>
>>>>> 1.4:
>>>>>
>>>>> (i) envelope->message to make sure people don't think they
>>>>
>>> can prefix
>>>
>>>>> the envelope with a PIII since that is not 'in' the envelope
>>>>>
>>>>> (ii) use of 'initial SOAP sender' instead of 'SOAP sender but not
>>>>> intermediaries'
>>>>>
>>>>> (iii) expansion of PI to processing instruction information item.
>>>>>
>>>>> (iv) reference to sender fault made consistent with the
>>>>
>>> rest of the
>>>
>>>>> spec.
>>>>>
>>>>> I hope you agree that the changes do not affect the semantics or
>>>>> general spirit of the issue resolution. Please let me know if you
>>>>> disapprove.
>>>>>
>>>>> Regards,
>>>>> Marc.
>>>>>
>>>>> -- 
>>>>> Marc Hadley <marc.hadley@sun.com>
>>>>> XML Technology Center, Sun Microsystems.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> -- 
>>>> Marc Hadley <marc.hadley@sun.com>
>>>> XML Technology Center, Sun Microsystems.
>>>>
>>>
>>>
>>
>>
> -- 
> Marc Hadley <marc.hadley@sun.com>
> XML Technology Center, Sun Microsystems.
> 
Received on Friday, 6 September 2002 11:28:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:22 GMT