RE: XMLP/SOAP spec - processing instructions

The XMLDecl is not a processing instruction.  

The historical context for the prohibition against processing
instructions in SOAP was that some people believed that processing
instructions were too expensive for small devices.  This was swept up as
part of a larger conviction that DTDs were too expensive.  I do not
believe that the actual cost of processing instructions was considered
separately and in detail. I deserve the majority of the blame for the
decision. Frankly, given the benefit of more time to think about the
matter, I now think that allowing them would have real benefits and
little cost.

-----Original Message-----
From: Bob Cunnings [mailto:cunnings@lectrosonics.com] 
Sent: Monday, May 21, 2001 10:35 AM
To: xml-dist-app@w3.org
Subject: Re: XMLP/SOAP spec - processing instructions



Hello,

Actually *most* implementations do send the "xml declaration"...

I seem to recall a discussion some time ago, maybe on the 
DevelopMentor list, on this topic. The issue was "Is the xml 
declaration really a PI as far as the intent of the prohibition in the
spec is concerned?".

The "xml declaration" is defined separately from PI's in the XML 
spec [1].

It is interesting to note that the examples in the spec don't contain a
prolog element.

RC

[1] http://www.w3.org/TR/REC-xml#sec-prolog-dtd

> The XMPL/SOAP spec (as well as the SOAP 1.1 spec) specifically 
> prohibits XML processing instructions (sec 3, para 4). I take this to 
> mean that the XML prolog (<?xml ... ?>)is prohibited.
> 
> Questions:
> 1. What is the rational for this? Can anyone (maybe Henrik or 
> Noah) shed any light on the historical context for this?  
> 2. Can we relax this prohibition in our spec and allow an 
> XML prolog? As long as it is optional I don't think it would
> break any existing applications.
> 
> Comments:
> 
> It seems like it might be useful to convey the XML version level 
> (particularly after versions 2.0 and 3.0 come out).
> 
> Also, the prolog can convey the character encoding. This may be useful

> in some situations. I realize that HTTP can carry the encoding in the 
> "Content-Type" header, but other bindings may not have a convenient 
> way to convey this information.
> 
>   Randy Waldrop
>   webMethods, Inc.

Received on Monday, 21 May 2001 14:35:54 UTC