RE: Problem with resolution of Issue 221

Hi Martin,

Can we separate two things...

1) Whether or not the resolution to #221 is clear and consistent.

2) Whether or not the imperatives a) MUST NOT send PIs and b) SHOULD
generate error/fault on receipt of PIs actually accomplish what the WG
wanted them to.

On 1), ok, I agree, the two sentences:

"Whenever possible, receivers should detect PIIIs and fault. The above rule
says SHOULD (as opposed to MUST) only to allow for implementations in which
performance considerations outweigh the desirability of detecting erroneous

do muddy things... up to that point it is very clear and consistent. The
'should' in the first of these sentences is not emboldened, which may be a
typo, so it is not clear whether the 'SHOULD' in the second sentence is a
reference to the 'should' in the first sentence or to the 'SHOULD' in the
sentence that immediately preceeds both these two:

SOAP receivers (including intermediaries) receiving a message with a PIII
SHOULD generate an error.

I took took it to be a reference to the 'SHOULD' in the sentence in this
second quoted block and not the 'should' in the first sentence in the first
quoted block.

If I have taken this reference correctly, then the resolution still remains
consistent... obviating the need to detect PIs  for the purposes of
generating a fault, but yes, agreeing with you still requiring DETECTION for
the case of supressing either messages or PIs in messages being
retransmitted by an intermediary.

However, Re 2) *if* it was the intent of the WG is that in all cases the
detection of PIs in inbound messages be OPTIONAL, then it has stated clearly
a consistent set of imperatives that DO NOT accomplish that intent. ie. its
made the wrong statement, it is not that the the statement it made has made
lack clarity or consistency with respect to a decernable intent.

As, you state the intent behind making PI detection a SHOULD (which the
resolution in [1] does not actually do - modulo a possible typo) is to
enable high performance intermediaries to avoid having to detect PIs when
relaying messages, I agree that the resolution is not consistent with that

However, the resolution in [1] does give a clear answer to the question
posed in Issue 221... it states clearly that a conforming intermediary MUST
NOT send a SOAP message that contains PI's (because an intermediary is also
a SOAP sender).

I've probably now left you completely exasperated... and I have considerable
sympathy with your comments about subsetting XML. FWIW I would be equally
happy with a resolution that stated *clearly* and *consistently* that SOAP
senders MAY send messages that contain PIs and that SOAP intermediaries MUST
relay PI's with as much fidelity as they would relay any other XML content
in a message at an equivalent point in the same message. Such a resolution
would certainly obviate the need for intermediaries to detect PIs in order
to comply with the spec.

Best regards


[1]  http:///

> -----Original Message-----
> From: Martin Gudgin []
> Sent: 14 August 2002 16:12
> To: Williams, Stuart
> Cc:
> Subject: RE: Problem with resolution of Issue 221
> The whole point of making the detection of PIs SHOULD rather than MUST
> was to allow high performance intermediaries to avoid the overhead of
> doing the PI detection ( they would have to look at the entire message
> ). BUT if they are precluded from sending messages containing PIs then
> they HAVE TO do the PI detection anyway, so any perf gain is lost.
> So we may as well make both of them MUST ( or SHOULD ) or, my 
> preference
> would be to stop trying to subset XML, say nothing about DTDs or PIs
> except that our spec doesn't define any processing rules for them.
> Gudge
> > -----Original Message-----
> > From: Williams, Stuart [] 
> > Sent: 14 August 2002 14:40
> > To: Martin Gudgin
> > Cc:
> > Subject: RE: Problem with resolution of Issue 221
> > 
> > 
> > Hi Martin,
> > 
> > Hmmm... not sure that this really is inconsistent... 
> > 
> > The MUST NOT is on senders sending PIs in messages.
> > 
> > The emboldened SHOULD is on receivers generating errors (are 
> > those faults and if so which one(s)) on receipt of PIs in messages.
> > 
> > There is a non-emboldened 'should' with "detect and fault" in 
> > "Whenever possible, receivers should detect PIIIs and fault." 
> > I took this as explainatory narrative, because the 'should' 
> > is not a 'SHOULD'. 
> > 
> > The conjunction of PI detection and fault generation muddies 
> > the intended strength of the imperative on detection and 
> > fault generation ie. MUST detect and SHOULD fault, or SHOULD 
> > detect and SHOULD fault etc...
> > 
> > To me the resolution seemed clear and consistent [1], ie MUST 
> > NOT send PIs; SHOULD generate error/fault on receipt of PIs. 
> > Detection of PIs becomes implicit in meeting those 
> > imperatives and need not be spoken about explicitly ( I 
> > think). Unless of course the intent of the WG in resolving 
> > this issue was different than that... then I guess clarity 
> > and consistency again fall into question.
> > 
> > Thanks,
> > 
> > Stuart
> > [1] 
> >
> .html
> > -----Original Message-----
> > From: Martin Gudgin []
> > Sent: 14 August 2002 10:42
> > To:
> > Subject: Problem with resolution of Issue 221
> > 
> > 
> > 
> > I was about to incorporate the resolution to issue 221[1]
> > when I noticed
> > an inconsistency:
> > 
> > We say that a sender MUST NOT send a message containing Processing 
> > Instructions. However, for receivers we only say SHOULD 
> detect PIs and
> > generate a fault.
> > 
> > In the case of an intermediary ( the case we were thinking 
> of when we 
> > said 'SHOULD' for receivers ) this will not work, as the 
> intermediary 
> > is also a sender. Therefore, in order to comply with the 
> MUST it has 
> > to detect PIs in the inbound message, otherwise when it sends the 
> > message onward, it might be violating the MUST.
> > 
> > On balance I think the best we can get away with is SHOULD NOT
> > 
> > Gudge
> > 
> > [1]
> > http:///
> > 

Received on Wednesday, 14 August 2002 12:10:36 UTC