Problems with PASWA ... and an alternative

I've been following the recent thread reviewing the Proposed Infoset
Addendum to SOAP Messages with interest particularly the differences
between:
a) Treating attachments as if they were part of the XML Infoset (which PASWA
proposes), vs
b) Treating attachments as first class citizens in their own right.
 
I can see benefits in both approaches in that efficiently putting a large
"blob" in an attachment in a way that is transparent to the application can
make the application processing simpler.
 
Alternatively, the idea of an attachment where the application is aware that
is an attachment as a separate item is equally valid, for example an
application that is processing an order that just happens to have terms and
conditions attached to it as a PDF.
 
I also have one concern (and also a question) over the way PASWA works as
described below ...
 
USING CID: IN XBINC:INCLUDE
There's a catch 22 here as:
1. You can only create the XML when you know the cid values to put in the
XML
2. You only know the cid values when you marshall XML into the SOAP Message,
but 
3. You can't marshall the SOAP message until you have created the XML. 
 
I know that you can get around this problem IF the generation of the XML and
the SOAP Message is done by the same software at the same time. Although
this will often be both possible and desirable it is, I think, something
that will often not be possible to do.
 
Here's some use cases that explain why. They all assume an XML document that
uses an xbinc:include element that references an attachment, e.g an XML
order that references a PDF document as described above:
1. The order and its attachment, is generated by an ERP system and passed to
a SOAP processor for forwarding to the supplier. The SOAP processor puts the
XML document into the SOAP body The problem is the ERP system does not know
anything about the SOAP Message and therefore can't set the href in the
xbinc:include. So, the SOAP processor must alter the XML to include it
instead. This means that the SOAP processor can no longer be a general
purpose processor as it must be payload aware.
2. This is a variation of 1 where the ERP system digitally signs the XML it
is generating. This means that the SOAP processor can't even alter the
original XML without breaking the signature. The only solution is for the
ERP system to tell the SOAP Processor the cid values to use somehow. However
the ERP system may not have the functionality that allows this.
3. The order and its attachments are sent to its destination. The
destination then archives the payload and attachments discarding the
original SOAP envelope. Some time later the payload is removed from the
archive and forwarded in another SOAP message together with the attachments.
The problem is how does the SOAP processor that is doing the forwarding know
what to use for the content ids in the MIME message.
 
The point is that I don't think that a tight coupling between the XML and
the SOAP message will often work or be practical.
 
HOW DOES PASWA WORK WITH WSDL
This is really more of a question than a concern in that PASWA ignores the
idea of Message Parts that is one of the fundamental concepts behind WSDL.
What is not clear to me is how you would decide to use separate message
parts rather than the transparent message parts that PASWA seems to suggest.
 
AN ALTERNATIVE APROACH?
Finally, Commerce One, has developed a soap header spec and an open source,
royalty free implementation (called DocSOAP) that uses a Manifest element
that is an extension of the ideas on a Manifest from ebXML Messaging. It
covers much (but not all) of the same ground covered by PASWA whilst solving
(we think) the problems with the use of content id described above as well
as tying it in more closely to WSDL.
 
The key difference between the SOAP Manifest and PASWA is that the XML
document references the WSDL partname for an attachment and then the
Manifest element in the SOAP header ties the partname to the content id of
the actual part which can be in the SOAP Body, in an attachment or even
externally to the message on the web. This means that the content ids can be
changed at any time and only the manifest element needs to change.
 
Anyway, the Manifest spec is available at:
http://www.commerceone.com/developers/docs/ws-soapmanifestv1_0.pdf
<http://www.commerceone.com/developers/docs/ws-soapmanifestv1_0.pdf> 
 
... and the open source, royalty free implementation (which also includes a
full featured XML parser and Bean generator) is available at:
http://www.commerceone.com/developers/docsoapxdk/
<http://www.commerceone.com/developers/docsoapxdk/> 
 
Thoughts and comments welcome.
 
David Burdett
 
Director, Product Management, Web Services
Commerce One
4440 Rosewood Drive, Pleasanton, CA 94588, USA
Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
 <mailto:david.burdett@commerceone.com>
mailto:david.burdett@commerceone.com; Web:  <http://www.commerceone.com/>
http://www.commerceone.com