Re: Proposed Infoset Addendum to SOAP Messages with Attachments

I can see that a lot of thinking has gone into to this. This brings us a 
lot closer to a solution. A few observations or comments.

1. I can kind of see why it was chosen to extend xs:base64Binary but, 
attachments in general are not binary. It seems odd that we could have 
another XML document sent as an attachment "Base64 encoded", because it 
was an attachment. I am not sure however if there is a good way around 
it (a union of some kind?).

2. I can also relate to the need for having a SOAP Infoset model (and 
the equivalence with the SwA model) etc. However, it should be 
recognized that (binary) attachments by their nature are large and 
Base64 encoding them makes them 33% larger. So, I tend to wonder if it 
really makes sense to inline (or include them) in the SOAP Envelope in 
general.

3. My understanding of the SwA attachment reference mechanism was to 
facilitate simply that,  reference an attachment. E.g.  here is the PO 
(in the SOAP Env) and here is the diagram showing the specs of 
line-item-1  in JPEG;  here is the spec for line-item-2 in JPEG; Two 
different images simply referenced from the PO.

So, keeping with that spirit and also trying facilitate the 
xbinc:Include scheme proposed and  the "Representation" aspects 
accounted for as well, why not define a swa:AttachRef type , that has 
the swa:mediaType attribute, and a href attribute that can have a value 
of a  URI like "http://example.org/me.png" (external) or 
"cid:me@example.com" (co-located). These can be kept as separate 
attributes if needed. If "swa:AttachRef:" extends xs:base64Binary, then 
a value present for an element of the type swa:AttachRef represents the 
(base64 encoded ;() inlined value of the attachment.  The equivalent of 
xbinc:DoInclude would still be needed I guess, to have the SOAP 
processing model aspects accounted for.

4. It is not clear to me why swa:Representation was chosen to be limited 
to be a SOAP:Header block only? I would think external references would 
be needed for attachments in the Body as well no? Perhaps combining the 
two constructs (xbinc:Include and swa:Representation) into one would 
obviate this..

Regards, Prasad

On Tuesday, Mar 25, 2003, at 12:41 US/Eastern, Martin Gudgin wrote:

> We have now posted the document illustrating an infoset approach to the
> attachment feature. You can find html[1], pdf[2] and word docs[3]. This
> document is intended to be a concrete realisation of the ideas laid out
> in the white paper at[4].
>
> Apologies for the delay.
>
> Gudge
>
> [1] http://www.gotdotnet.com/team/mgudgin/paswa/paswa.html
> [2] http://www.gotdotnet.com/team/mgudgin/paswa/paswa.pdf
> [3] http://www.gotdotnet.com/team/mgudgin/paswa/paswa.doc
> [4] http://www.xml.com/pub/a/2003/02/26/binaryxml.html
>

Received on Wednesday, 26 March 2003 22:21:02 UTC