Andreas, Thank you for the quick reply.
It's actually point 5 of section 3.1 that motivated my original email. It seems to indicate that <xop:Include> is a serialized element in the XML Infoset, not text under the <ns:Document> element (thus white spaces between <ns:Document> and <xop:Include> should be ignored by the parser). I agree the base64binary form should contain no preceding or trailing white spaces on the <ns:Document> text. If the SOAP response contains this: <Document><Include xmlns="http://www.w3.org/2004/08/xop/include"; href="cid:urn:uuid:56443C4239C2E4EC851238526572016"/></Document> Then I only see one child under <ns:Document> and the serialized form is correct. Unfortunately this isn't my service, I'm just a consumer of it. Thanks, -Matt On Wed, Apr 1, 2009 at 2:54 PM, Andreas Veithen <[email protected]>wrote: > Matt, > > If my interpretation of the specs [1] is correct, then your service > doesn't return a valid XOP package (see points 3 and 4 in section > 3.1). > > Andreas > > [1] http://www.w3.org/TR/xop10/ > > On Wed, Apr 1, 2009 at 23:32, Matthew Davis <[email protected]> wrote: > > Hi, > > > > I've run into an interesting problem with MTOM response handling. Not > sure > > if this is a bug or intended functionality to keep schema compliance (not > an > > expert in MTOM+XOP). Currently using Axis2 v1.4.1 and Axiom v1.2.7. > > > > The service I'm calling is returning responses as SOAP/MTOM+XOP, but the > > SOAP is pretty-printed (kind of, mainly line breaks between elements). > The > > problem I'm running into is with the recombination of the XOP parts into > the > > XML (base64binary fields). The MTOM builder keeps the line breaks > between > > <Document> and <Include> intact after building, even though it seems to > be a > > proper XML element hierarchy. See the following snippet from the SOAP > > payload: > > > > <Document> > > <Include xmlns="http://www.w3.org/2004/08/xop/include"; > href="cid:urn:uuid: > > 56443C4239C2E4EC851238526572016"/> > > </Document> > > > > It finds the attachment(s) without problem. But, when I call > getChildren() > > on the <Document> element, I get three OMText nodes: > > > > 1) OMText: "\n" > > 2) OMText: The optimized node containing the binary data and > Datahandler > > 3) OMText: "\n" > > > > and when I call serialize and print, the line breaks remain: > > > > <Document> > > [base64-encoded text] > > </Document> > > > > Please let me know if this should be directed to the AXIOM folks instead. > > > > Thanks, > > -Matt >
