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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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?
> ...

Reply via email to