Re: SOAP's prohibiting use of XML internal subset

Paul Grosso wrote:

> It is my understanding that the Last Call draft of SOAP 1.2 [7] makes
> use of an XML format that does not permit any internal subset, despite
> the fact that XML 1.0 does not define such a profile/subset of XML.  I
> wonder what the definition of such profiles by individual specifications
> will do for interoperability.  

I hate to say it at this late date, but I think Paul's really got a 
point here.  In particular:

- The IETF has recently adopted Guidelines for the Use of XML Within 
IETF Protocols as a Best Common Practice (see 
http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-07.txt, 
and there's HTML at 
http://www.imc.org/ietf-xml-use/xml-guidelines-07.html).  It 
specifically in section 4.3 "Syntactic Restrictions" advises against 
doing what SOAP 1.2 is doing.  I think the Web Services community ought 
to be real nervous about flying in the face of an IETF BCP.  The BCP is 
really well-written on this point and worth checking out.

- On the other hand, I think it's entirely reasonable that SOAP agents 
be forbidden from being required or expected or even allowed to charge 
off fetching DTDs or external parameter entities at run times, for 
obvious performance and security reasons.

- That granted, forbidding an internal subset seems kind of dumb. 
Speaking as an XML processor implementor, the extra code required is 
hardly detectable and the performance gain not significiant. 
Furthermore, every XML processor in the world just silently does the 
internal subset and it's going to cost *extra work* for SOAP 
implementations to check that they haven't.  I.e. you can't use an 
ordinary off-the-shelf non-validating XML processor.

- I'd be willing to bet that at least some SOAP implementations don't 
bother to implement this restriction, which raises real interoperability 
issues.  Does that have an impact on CR exit criteria?

  -Tim

Received on Monday, 25 November 2002 16:34:55 UTC