Passing XML Documents

[Jason Nesbitt <ja...@gmail.com>]

I need to create a web service where the payload will be an industry
standard xml document.  What's the best way to have the client package
the xml doc into the soap message?  Sun says that there are three ways
to do this.  See
http://java.sun.com/blueprints/guidelines/designing_webservices/html/webservdesign8.html.
1. The xml doc could be sent as an attachment. 
2.  The message part could be definined as an xsd:String type.
3.  The message part could be definined as an xsd:anyType

The problem with option 1 above is that Sun says it's not very
interoperable.  I'm not sure why.  I'm not sure if 2 and 3 would work
because the documents being sent would likely have xml and doctype
declarations (The document has a dtd).  Obviously, these declarations
are not elements and when embedded in a soap message would result in
the message not being well formed xml. Would those declarations
possibly be encoded?  What would the difference be between xsd:String
and xsd:anyType with the way the messages would look over the wire?
Another option that has been discussed would be to skip using SOAP and
just pass the xml doc as the payload of an http post.  Might this be a
better solution?  Any opinions on the merits of this?

Thanks for your input.

Jason  

p.s.  Anyone need a gmail account?  I've got six left to give out.

Re: Passing XML Documents

[Jeff Greif <jg...@alumni.princeton.edu>]

The big problem is the doctype which IIRC is only legal in the document
prolog before the root element; hence not in the Body of the soap message.
If it weren't for this, the document could be one of the arguments of an RPC
web service call, or the single element or one of its descendant elements in
a doc/lit WS invocation.  If the doctype is always the same whenever the
payload is valid, the client could strip it off, pass the rest as a
parameter to the service, and the service implementation could put it back
on before doing whatever else it does.  This would only work if there were
no entities defined in either the internal subset of the doctype or the DTD,
since in that case the service will be deserializing it without the doctype
or dtd.  Something more tricky might be done by hooking the deserialization
process to splice in the doctype just as it was starting,   This would be
implementation-dependent in the service infrastructure.

If the doctype varied from call to call, it could be stripped off (with
caveats as above) base64-encoded as a parameter of the service, and then
reassembled in the server.  This would be nastier if the doctype were needed
for deserialization of the other content.

The anyType solution would not work unless all the content, especially the
doctype, were escaped.  It might as well be a string then.  You might as
well just compress and base64-encode it if doing that, which is probably
more efficiently handled as an attachment.

If you have some idea of the interoperability requirements, the attachment
solution seems cleanest, assuming you are allowed to have doctype in
attachments (this is out of my realm of knowledge) or are willing to encode
the attachment somehow.

Jeff



----- Original Message ----- 
From: "Jason Nesbitt" <ja...@gmail.com>
To: <ax...@ws.apache.org>
Sent: Thursday, September 30, 2004 7:42 AM
Subject: Passing XML Documents


> I need to create a web service where the payload will be an industry
> standard xml document.  What's the best way to have the client package
> the xml doc into the soap message?  Sun says that there are three ways
> to do this.  See
>
http://java.sun.com/blueprints/guidelines/designing_webservices/html/webservdesign8.html.
> 1. The xml doc could be sent as an attachment.
> 2.  The message part could be definined as an xsd:String type.
> 3.  The message part could be definined as an xsd:anyType
>
> The problem with option 1 above is that Sun says it's not very
> interoperable.  I'm not sure why.  I'm not sure if 2 and 3 would work
> because the documents being sent would likely have xml and doctype
> declarations (The document has a dtd).  Obviously, these declarations
> are not elements and when embedded in a soap message would result in
> the message not being well formed xml. Would those declarations
> possibly be encoded?  What would the difference be between xsd:String
> and xsd:anyType with the way the messages would look over the wire?
> ...

RE: Passing XML Documents

[Anne Thomas Manes <an...@manes.net>]

Are you saying that the payload must be a separate XML document with its own
<?xml> header? Or is your requirement only that the payload contains an XML
structure that conforms to the standard XML schema (an XML fragment)? 

If you must send a separate document rather than a document fragment, then
Sun's recommendations are accurate, although is the document includes the
doctype declarations, then option #3 won't work.

Option #1 will cause interoperability problems because the industry has not
reached consensus on how to send SOAP attachments. .NET supports only DIME
attachments, and a number of Java implementations (including Sun's JWSDP)
support only MIME attachments. (Note that Axis supports both DIME and MIME.)

Option #2 is probably your best bet. The XML document is serialized as a
string and this value is then embedded in an element of type xsd:string.
It's not passed as XML, so it doesn't impact the wellformed-ness of the SOAP
message.

Option #3 works only if you are sending an XML fragment rather than an XML
document.

If you can send an XML fragment, then you should actually import the
document's schema into the WSDL. The message part can then be defined as the
root element of the document.

Anne

-----Original Message-----
From: Jason Nesbitt [mailto:jason.nesbitt@gmail.com] 
Sent: Thursday, September 30, 2004 4:43 PM
To: axis-user@ws.apache.org
Subject: Passing XML Documents

I need to create a web service where the payload will be an industry
standard xml document.  What's the best way to have the client package
the xml doc into the soap message?  Sun says that there are three ways
to do this.  See
http://java.sun.com/blueprints/guidelines/designing_webservices/html/webserv
design8.html.
1. The xml doc could be sent as an attachment. 
2.  The message part could be definined as an xsd:String type.
3.  The message part could be definined as an xsd:anyType

The problem with option 1 above is that Sun says it's not very
interoperable.  I'm not sure why.  I'm not sure if 2 and 3 would work
because the documents being sent would likely have xml and doctype
declarations (The document has a dtd).  Obviously, these declarations
are not elements and when embedded in a soap message would result in
the message not being well formed xml. Would those declarations
possibly be encoded?  What would the difference be between xsd:String
and xsd:anyType with the way the messages would look over the wire?
Another option that has been discussed would be to skip using SOAP and
just pass the xml doc as the payload of an http post.  Might this be a
better solution?  Any opinions on the merits of this?

Thanks for your input.

Jason  

p.s.  Anyone need a gmail account?  I've got six left to give out.