RE: Issue 4 Proposed Resolution (was: why no doc type declarati on and PIs in SOAP)

> -----Original Message-----
> From: Paul Denning [mailto:pauld@mitre.org]
> Sent: Sunday, September 30, 2001 7:23 AM
> To: xml-dist-app@w3.org
> Subject: Re: Issue 4 Proposed Resolution (was: why no doc type
> declaration and PIs in SOAP)
> 
> 
> Recommend:
> 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 
> NOT process the  SOAP message at all, and MAY generate a fault (see 4.4
SOAP 
> Fault) with  faultcode of "Client.DTD" or "Client.PI" respectively.

Let's think about what we're trying to accomplish here:  DTDs and PIs are
legal parts of XML syntax and there is no XML mechanism to say "you cannot
put a DTD or PI in an instance for this application." On the other hand,
they contain or imply all sorts of stuff that has historically caused both
implementation complexities and interoperability problems, and we don't want
SOAP users to have to deal with these problems.  BUT we want to leverage the
existing XML infrastructure to promote the introduction of SOAP.  FInally,
we know from experience that anything not explicitly forbidden will be done
by someone or other, and if that someone is a dominant player in some part
of the industry, other players will have business reasons to be "bugwards
compatible," thus making conformance with the spec only a fuzzy guideline
rather than a guarantee of interoperability.

My first thought was that DTDs and PIs should be quietly ignored by SOAP
processors, i.e., they would not be rejected (because they are legal XML
syntax) but nothing in the syntax should show up in the SOAP infoset. If so,
some wording to the effect that a SOAP processor MUST NOT exploit any
information in a DTD or PI and and MAY generate a fault would be
appropriate; that would allow a SOAP to leverage generic XML tools rather
than forcing SOAP syntax parsers to be specific to SOAP.

BUT there's a fly in that soup:  a generic XML parser will quietly expand
character entities defined in the DTD internal subset before the SOAP
processor even sees them, and may even expand external parsed entities.  PIs
are somewhat less of a problem, but you could imagine a processor that
understood the PI for stylesheets doing the PI-defined defined XSLT
transformation before passing it on (which would be the "right thing" in a
browser, but definitely not in a SOAP processor).    

So, I have to admit (this was NOT my belief when I started writing this
message!) that quietly ignoring DTDs and PIs will probably not work in
practice. The cleanest thing to do is what Paul Denning recommends. A SOAP
implementation will have to check for DTDs/PIs before sending text to a
generic XML parser, or has to work with the parser (or the infoset it
produces) to detect DTDs and PIs, and generate a fault.  This achieves our
two fundamental objectives of ensuring interoperability while leveraging XML
infrastructure, although granted it does force a SOAP processor to do some
checking before or after the generic XML processing.

An even better solution would be to work with the XML Core people to define
an XML conformance level [e.g., <?xml version="1.0a"?> or <?xml
version="1.0nodtd"?> or something ] corresponding to SOAP's needs.  This
would allow generic XML parsers to enforce the restriction (or a parser
could quietly refrain from using DTD information to generate the infoset, I
suppose). I have never seen any signs of interest in an XML conformance
level below 1.0, however, so I think we're on our own here.

Received on Sunday, 30 September 2001 10:28:43 UTC