- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Thu, 20 Sep 2001 14:13:03 -0400
- To: xml-dist-app@w3.org
> -----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 from 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 02:41:10 UTC