RE: SOAP's prohibiting use of XML internal subset

This thread will lead back to the question 
of whether support for DTDs, internal subset 
et al should be in the XML 1.0 core, or removed 
to coincide with the lowest common denominator 
applications of the specification.   It may be 
that this can only be fixed by a new version of 
that specification.  It seems unlikely but isn't 
unthinkable given the need to integrate implementation 
experience back into living specifications.

Should other specifications be able to subset 
XML 1.0?  No, not and claim that their processors 
are conformant.  This can as pointed out lead 
to interoperability problems (noted as of yet 
or not) and it invalidates the claims asserted 
in the XML 1.0 specification and claims made 
by reference to it.

len

From: Mark Nottingham [mailto:mnot@mnot.net]

>  I think the Web Services community ought
> to be real nervous about flying in the face of an IETF BCP.

Why? It's a Best Current Practice, and it is explicitly scoped to use of
XML within *IETF* protocols. It's just that community's best current
thinking (words directly from RFC2026) on a particular topic, and may
(dare I say probably will) change.

Granted, if there is a desire to make it possible to use Web services as
the basis of IETF protocols, there might be cause for concern; however,
that isn't a requirement that I've heard for a while, and I imagine that
the IETF isn't terribly inclined to start using them willy-nilly either;
Web services have a different audience.


> - 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.

This gets to the heart of the question, I think; can specific applications
of XML restrict the use of syntactic mechanisms it defines? The answer
seems to be "yes." I don't think it's supportable to be selective about
this, at least at this granularity.


> - 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.

Perhaps the WG has a good reason for this prohibition; have they been
asked?

Received on Monday, 25 November 2002 17:21:09 UTC