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

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

From: Doug Davis <dug@us.ibm.com>
Date: Sat, 29 Sep 2001 08:12:52 -0400
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
Cc: xml-dist-app@w3.org
Message-ID: <OF0C2E7B03.08D4FBDA-ON85256AD6.0043263E@raleigh.ibm.com >
+1 - the inconsistency between how we're dealing with the two does seem

"Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>@w3.org on 09/20/2001
02:13:03 PM

Sent by:  xml-dist-app-request@w3.org

To:   xml-dist-app@w3.org
Subject:  RE: why no doc type declaration and PIs in SOAP?

> -----Original Message-----
> From: Francis Norton [mailto:francis@redrice.com]
> Sent: Thursday, September 20, 2001 1:05 PM
> To: Champion, Mike
> Cc: xml-dist-app@w3.org
> Subject: Re: why no doc type declaration and PIs in SOAP?
> >
> Are SOAP payloads allowed to contain DTDs and PIs?

I don't know ... I may have been led astray by the analogy with xml:base.
In that discussion, we agreed that we weren't trying to prevent xml:base or
relative URIs from being used in the payload, only the SOAP envelope.

Reading through the F2F draft minutes, it appears that the xml:base and
PI/DTD issues were discussed at more or less the same time, and apparently
the XML Core WG has gone on record as strongly discouraging the XMLP WG
defining anything but the full XML 1.0 + Namespaces + XML Base
specifications as the meta-syntax for SOAP.  As with xml:base, I'm not sure
how much of a *practical* problem this would pose developers, but I
personally have philosophical problems with this.  I wish that there were
some way in XML (or Schema) to define a "profile" of the features that some
specific application actually needs, so that specialized processors can
focus only on those features and not all the stuff (e.g., PIs and external
entities) that cause interoperability problems in practice. There isn't a
formal way to do this in XML (there was in SGML, I believe), but it seems
that we should be allowed to do this in the language of the SOAP spec.

My perspective is: So long as SOAP data can be processed with generic XML
processors, I don't see a problem if SOAP processors can't handle generic
XML data.  I'd be interested in discussing realistic use cases where this
would cause practical problems.  For what it's worth, I'm not sure whether
SOAP processors should quietly ignore or loudly reject XML constructs that
are not defined in SOAP.  That seems to be a separate discussion.
Received on Saturday, 29 September 2001 08:14:11 UTC

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