Re: SOAP's prohibiting use of XML internal subset

Mark Nottingham wrote:

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

If you think that the design issues around IETF protocols are not 
similar to those in the SOAP arena, you're welcome to your opinion, but 
I think the evidence is against you.  Also, the current document 
represents the results of a months-long process with a large number of 
participants, I don't think you can airily say "oh, just ignore this 
because it will probably change."

> Also, at first glance, the logic in that document seems to be faulty; it
> says one shouldn't impose "additional restrictions beyond those imposed by
> the XML recommendation itself" because "an implementer of the protocol may
> not be able to use an otherwise conforming XML processor to parse the
> XML-based protocol elements."
>
> If they are truly restrictions, how could a conformant processor not be
> able to parse the result? I grant that a vanilla conforming generator
> *may* have difficulty, depending on the abstraction that it presents to
> the programmer.

It is trivially easy for the user of a conforming XML processor to check 
which elements and attributes are in use and their contents.  It is 
trivially easy for the user to forbid the processor from resolving or 
fetching external entities.  There are no de facto or de jure 
standardized ways to check things such as "does the internal subset 
exist" or "was this character & or &" or "are the attribute 
values single or double quoted"?  For this reason, the latter kind of 
constraint is highly questionable in language designs.

> >- 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? Your answer
> seems to be a conditional "yes."

My answer is an absolute "no" at the syntax level.  Whether or not a 
processor fetches external entities is explicitly made optional and is 
controllable through every de jure and de facto standard.  It has 
nothing to do with syntax.

> However, I don't think it's supportable to be selective, at least at this
> granularity.

Well, I think it's trivially easy to be selective about things that the 
standards wire in support for (e.g. what elements and attributes, their 
order, whether you validate or not) and highly questionable to do 
low-level syntax redesign from spec to spec, for reasons of basic 
interoperability.  -Tim

Received on Monday, 25 November 2002 18:00:48 UTC