W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2003

RE: Handling the XML Prolog inside SOAP

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 23 May 2003 20:21:41 -0400
To: "Burdett, David" <david.burdett@commerceone.com>
Cc: "XML Dist-App (E-mail)" <xml-dist-app@w3.org>
Message-ID: <OF4092AE68.9D2FB6DF-ON85256D2F.0078F12E@lotus.com>

David,

Sorry for the slow reply on this.  I've been traveling a lot and have been 
quite backed up on email.  I'm not quite sure where to go with this, as I 
think we've about covered the bases.  SOAP was from day 1 an XML-based 
protocol, and that brought with it limitations.  I think we're agreeing on 
what those are.  As you point out, one can point to potentially useful 
scenarios which, though they can be handled by SOAP, are somewhat 
inconvenient and unnatural.  The payoff for this use of XML is, as I said 
in my last note, the ability to generate SOAP envelopes and to manipulate 
SOAP envelopes using XML tools. 

One of your scenarios involves essentially tunnelling another  protocol 
through SOAP, in the sense that you describe a message generated by a 
non-SOAP node that has to be then relayed through SOAP.  Presumably such a 
message does not participate in the SOAP processing model on an end-to-end 
basis anyway.  I'm not sure it's particularly unnatural to "tunnel" it 
through SOAP using base 64.  If you follow the PASWA proposal, there is 
reason to be optimistic that typical implementations will avoid the 
implied character conversions.

You also point out some tricks that can be used to tunnel just the parts 
of a document that XML doesn't nest gracefully.  I'm not sure whether 
that's actually a good technique, but I think SOAP allows it.  One 
suggestion:  I've noticed a lot of proposals that attempt to allow exactly 
one nested XML document in a SOAP message, and this doesn't feel right to 
me.   I think any effort to allow a SOAP message to carry an XML document 
should allow it to carry more than one.  That means that thinks like IDs 
might conflict between the multiple nested documents, and so on.  I think 
XML could have been designed with sufficient flexibility and scoping to 
make this happen, but it was not.  As it stands, I'm cautiously optimistic 
that the PASWA-based proposals will be tractable, even for nested XML.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Burdett, David" <david.burdett@commerceone.com>
Sent by: xml-dist-app-request@w3.org
05/14/2003 05:13 PM

 
        To:     "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>
        cc:     "XML Dist-App (E-mail)" <xml-dist-app@w3.org>
        Subject:        RE: Handling the XML Prolog inside SOAP



Noah

Thanks for the feedback. I realise and accept that this is really a 
problem
of XML rather than SOAP. That said, the use case I had in mind was one 
where
XML was being generated and transported internally using some non-SOAP
protocol (e.g. a MOM transport) which eventually gets to an outbound 
server
where the XML needs to be packaged up and sent using SOAP.

I think this means that architecturally there needs to be a separation of
the layers between the layer that is generating the content (the XML
document) and the layer that is transporting the content (e.g. SOAP + 
HTTP).
From what you say below, the only way to realize this separation seems to 
be
to use SwA (or some variant) or Base64 encoding.

On the other hand, you could equally imagine a different implementation of
the same message where the XML Content and SOAP were generated at the same
time and therefore there would be no need to use SwA/Base64 encoding since
all the potential conflicts you mention below could be resolved at message
generation time.

Now given that I think need to do this type of separation will be common -
think legacy ERP system with a SOAP front end, wouldn't this mean that if
you were designing a message that could be handled with both types of
implementation, then you would have to always use SwA/base64  as the way 
of
packaging the XML document if you did not want to impose architectural
constraints on an implementation?

Alternatively, could you make it possible to transport any arbitrary XML
document in the SOAP body by:
1. Stripping the prolog from the XML document and placing the rest of the
document inside the SOAP body.
2. Creating a SOAP Header/Feature, to carry the prolog information inside 
a
CDATA section as in, for example: <Prolog><![CDATA[<?xml
version="1.0"?>]]></Prolog>
3. On receipt, recreate the original XML document by concatenating the
content of the prolog element with the content of the SOAP Body?

Then, if you needed to recreate the complete XML document you could if you
wanted to.

Regards

David


-----Original Message-----
From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
Sent: Tuesday, May 13, 2003 7:55 PM
To: Burdett, David
Cc: XML Dist-App (E-mail)
Subject: Re: Handling the XML Prolog inside SOAP


Short answer:  no, you're not missing anything.  A fundamental decision in 

SOAP was to model messages primarily as XML.  This gives us lots of 
synergy with XML tools, schema languages, etc., but it means we also pick 
up the limitations of XML.  In general, it is not possible 
(unfortunately!) to nest multiple XML documents in a single outer 
document. That's an XML limitation, not particular to SOAP.   Any DTD 
would have to be at the outside, and all its declarations (for IDs, 
entities, and the like) would apply to the entire document.  IDs could 
conflict or IDREFS could be unintentionally resolved, etc.   Depending on 
how you do it, there can be issues with default namespaces, etc.  I think 
this is probably one of the major design flaws in XML, but there it is. 
Nested XML documents can be carried in SOAP as attachments using the 
attachment technology of your choice, or as base64binary or hexBinary 
encodings. 

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Burdett, David" <david.burdett@commerceone.com>
Sent by: xml-dist-app-request@w3.org
05/13/2003 12:49 PM

 
        To:     "XML Dist-App (E-mail)" <xml-dist-app@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Handling the XML Prolog inside SOAP


I'm reposting this question as I did not get any response earlier.
 
The SOAP PR spec [1] states a SOAP message must not contain information 
that often goes in the XML Prolog such as: document type declarations, 
processing instructions or comments before the main document element.
 
A question. What should you do if the XML that you want to transport was 
originally a complete XML document (perhaps digitally signed) that 
contains this type of information and you want this information to be 
preserved when the document reaces the ultimate destination so that it can 

be used?
 
My reading of the current SOAP spec suggests that this is not possible 
unless you Base64 encode it ... or am I missing something.
 
David
PS I realise this may have been already discussed but I missed it.
 
[1] http://www.w3.org/TR/soap12-part1/#soapenv 
Received on Friday, 23 May 2003 20:31:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:14 GMT