Re: Issue 4 Proposed Resolution (was: why no doc type declaration and PIs in SOAP)

Just a few comments, below, stemming from your wording...

On 01/09/28 11:35 AM, "Marc Hadley" <marc.hadley@sun.com> wrote:

> All,
> 
> As the custodian of issue 4 I'd like to propose the following resolution
> and rationale.
> 
> Proposed Resolution:
> 
> A SOAP message MUST NOT contain a Document Type Declaration or
> Processing Instructions. On receipt of a SOAP message containing a
> Document Type Declaration or Processing Instruction a SOAP receiver MUST
> either ignore it or generate a fault (see 4.4 SOAP Fault) with faultcode
> of "Client.DTD" or "Client.PI" respectively.
> 

When you say 'ignore it' do you mean the 'ignore the processing
instruction/DTD' or 'ignore the message'. It isn't clear from the wording.

Now, being a new member of this list, I don't know the history of this
discussion, so I am faced with two readings.

If I assume you meant 'ignore the PI/DTD' (and after reading the references
in your email this is what I believe you must mean): This gives the server
the alternatives of i) ignoring the error and presumably processing the
request; and ii) failing and so not processing the request. This seems to me
to be two alternatives that are equally acceptable yet representing two
extremes in outcome. I'd have to think that this will be the source of some
surprise to someone sometime. I also wonder about portability across
implementations (one processor processes the message the next ignores it).
I'd also think that when the message 'MUST not' contain PI/DTD yet still
might be processed, trouble is about to happen. I'd think that in the face
of a 'must' definition the response should also be a 'must'. So I have to
assume there is  a good reason for not demanding the failure of the message.

The references seem to indicate that this choice must be allowed because it
is too difficult to do otherwise ('this adds unnecessary complexity,
especially for PIs' in the third reference). I have two complaints with
this. First, as you might imagine, I question the 'unnecessary' bit. Second,
I wonder what kind of complexity it adds in practice? Is it the detection of
the error, or a difficulty in explaining the root cause of the problem once
detected (the processor sees something wrong, but cannot tell what the
problem is: DTD, PI, or maybe some other error, say not well-formed XML).
I'd then wonder how it is that the processor can possibly ignore it if the
processor doesn't know what it is and still get a message to process (how is
it that the message can be parsed?).

I'm also wondering what risks are being undertaken when processing what
amounts to an incomplete message, at least in the opinion of the client.
Surely the PI/DTD are there for a reason.

Sorry if these are all miss-placed concerns. Perhaps, in that case, someone
could point me to a suitable reference.

Thanks,
Bob

Received on Friday, 28 September 2001 22:09:46 UTC