RE: Problems with PASWA ... and an alternative

 

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of Burdett, David
> Sent: 08 May 2003 02:03
> To: XML Dist-App (E-mail)
> Cc: DocSOAP Developers (E-mail)
> Subject: 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

I don't understand why I need to know the values. I'm writing XML
elements along with their children; other elements, characters. At some
point I want to 'write' the PDF. I would just pass the PDF ( in stream
or byte array form ) to my writer and tell it "it's binary, do the right
thing'. If the writer I'm using is NOT PASWA aware, it will either give
up, or hopefully convert to base64. If it is PASWA aware, it will
serialize a xbinc:Include element ( and synthesise a value for the href
) and then serialize the PDF as raw-octets once it's done serializing
the SOAP envelope.
 
> 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, 

I think the mismatch is in assuming that you would construct XML that
contained xbinc:Include elements in the first instance. I would never do
such a thing.

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

You are assuming it is necessary to sign the @href of the xbinc:Include.
I would assert that it is NOT necessary to do that, rather you sign the
parent element and it's content ( whether as raw-octets or base64 is a
separate ( answerable ) question ).

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

I don't understand the relationship between the 'payload' and the
attachment.

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

I think the XML looks just as it ever did ( and does NOT contain
xbinc:Include elements ). The SOAP layer MIGHT serialize using
xbinc:Include, but the application layer need never see them.

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

I think you just define messages with XSD types and anything that is of
type xsd:base64Binary is a potential attachment.

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

I'm not convinced there is a problem with cids.

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

With PASWA the content-ids can be changed at any time and only the
corresponding xbinc:Include/@href needs to be changed.

Gudge

Received on Wednesday, 14 May 2003 11:39:33 UTC