W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2001

Re: why no doc type declaration and PIs in SOAP?

From: christopher ferris <chris.ferris@Sun.COM>
Date: Fri, 21 Sep 2001 11:07:51 -0400
Message-ID: <3BAB57C7.2F77C74B@Sun.COM>
To: Rich Salz <rsalz@zolera.com>
CC: Jacek Kopecky <jacek@idoox.com>, xml-dist-app@w3.org
Rich Salz wrote:
> Chris,
> I have a slight problem with saying "this message is non compliant" but
> then saying what receivers should do when they get one.  If I choose to
> send the weasels after someone who sends me a DTD, that shouldn't count
> against me in the compliance scorecard.  (Recall that you only get a
> limited number of SHOULD violations.)  My mind's not firmly made up, but
> I tend to side with Jacek that the level of obligation must be the same
> on both sides.
>         /r$
> --
> Zolera Systems, Your Key to Online Integrity
> Securing Web services: XML, SOAP, Dig-sig, Encryption
> http://www.zolera.com

I disagree. By saying that a SOAP Sender SHOULD NOT send
a message with a DTD or PI means that a compliant SOAP
implementation COULD do so which is not what we want. 

All I am proposing is that we define the exception handling
requirements (which boils down to MAY ignore) of a SOAP Receiver
that (hopefully) don't impose unnecessary added complexity
just to cover a rogue case.

If we were for instance to say that a SOAP Receiver MUST
send a Fault, then that implies that it MUST look for PIs
which adds unnecessary complexity IMO because a PI MAY ALWAYS
be safely ignored.

The DTD problem is a little trickier, but I think that 
aside from adding the minor overhead of weeding it out with a
rather trivial regex or some equivalent is enough, and that 
adding a requirement that a SOAP Receiver cannot simply
ignore it (e.g adding logic to generate a fault) is again adding
unnecessary overhead.

Saying that a SOAP Receiver MAY return a Fault, and calling out the specific
fault that if returned SHALL or MUST be used provides for 
a level of interoperability to handle rogue cases without
unnecessarily burdening it with a requirement to look for them
if it doesn't need to.

Normally, one could say in a spec that something MUST not be
done, but in this case, by excluding DTDs we are subsetting XML1.0
and I think that in this case it deserves to be explicitly called out
what to do when someone sends a non-compliant message.


Received on Friday, 21 September 2001 11:07:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:15 UTC