Andreas, Thanks for your response. I get your point. Will just write a workaround.
Thanks again On Wed, Apr 1, 2009 at 3:51 PM, Andreas Veithen <[email protected]>wrote: > Whitespace is never ignored by the parser: > > "An XML processor must always pass all characters in a document that > are not markup through to the application. A validating XML processor > must also inform the application which of these characters constitute > white space appearing in element content." > > Andreas > > On Thu, Apr 2, 2009 at 00:15, Matthew Davis <[email protected]> wrote: > > 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 > > > > >
