W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2000

RE: Question re: XML embedding in XML-dist protocols

From: <Noah_Mendelsohn@lotus.com>
Date: Mon, 8 May 2000 14:22:50 -0400
To: Sami Khoury <sami@whatuwant.net>
Cc: der@hplb.hpl.hp.com, xml-dist-app@w3.org
Message-ID: <OF4352DA5C.CB788C7F-ON852568D9.006489ED@lotus.com>
For better or worse, I am not aware of any standard means of doing this in 
SOAP version 1.1, but SOAP does now allow you to define your own encodings 
for data.  It is straightforward to do an encoding which would represent 
either some particular XML schema, or schemas in general.  In other words, 
you can send your own XML.  I do think this is something that the soap 
community should consider doing in a standardized manner, but in the 
meantime you can make ad hoc agreements with your friends. 

This does raise a philosophical question: if you believe that SOAP is only 
and fundamentally about RPC to invoke programming language constructs, 
then the above is a misuse of the coding mechanism, since the XML you 
would be transmitting would not necessarily map well to the structs and 
arrays discussed in SOAP chapter 5.  If you believe, as I do, that version 
1.1 is specifically to lay the groundwork for using SOAP for messaging 
models beyond RPC, then such encoding becomes a natural and 
straightforward thing to do.

In general, you might want to take this discussion to the SOAP mailing 
list (SOAP@DISCUSS.DEVELOP.COM).  Thank you,

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

Sami Khoury <sami@whatuwant.net>
Sent by: xml-dist-app-request@w3.org
05/08/00 02:11 PM

        To:     "'Dave Reynolds'" <der@hplb.hpl.hp.com>, xml-dist-app@w3.org
        cc:     (bcc: Noah Mendelsohn/CAM/Lotus)
        Subject:        RE: Question re: XML embedding in XML-dist protocols

You're not unusual for trying to do this :-)

ICE supports this out of the box (the item that is sent may be an entire 
node tree).  However, if your application is more about simple method
invocation than syndication, SOAP or XML-RPC might be more relevant.


-----Original Message-----
From: Dave Reynolds [mailto:der@hplb.hpl.hp.com]
Sent: Monday, May 08, 2000 9:01 AM
To: xml-dist-app@w3.org
Subject: Question re: XML embedding in XML-dist protocols

One of the attractions to me in using an XML-based protocol is that it
should be easy to exchange information already encoded in XML. For
example, as part of a command I might like to be able to pass a block of
metadata encoded in RDF, or a signed assertion encoded using
XMLSignature, or an embedded web document fragment in raw XML. To be
clear, I'm not talking about just sending such an XML packet over HTTP
(an easy job) I'd like the packet to be one of a number of parameters to
a service and to use some RPC mechanism to encode the other parameters.

The protocols I've looked at so far (XML-RPC, SOAP 1.0 and 1.1) provide
serialization algorithms for conveying standard datatypes over XML. They
don't seem to include any hooks for including a datatype to represent an
embedded XML node tree which I could include within the payload. Soap
1.1 would *allow* me to define such a thing by using the encodingStyle
attribute but doesn't seem to have such a thing out of the box. I guess
I'm looking for an <embedded-xml> element which would prevent the
deserialization algorithm descending further and would expose the XML
sub-tree to the client/server as a DOM (or DOM2, or jdom or whatever)
node for further parsing.

1. Is this a reasonable sort of requirement? Am I just unusual in even
trying to do this!
2. Is there some capability along these lines already available or

Dave Reynolds
Hewlett-Packard Laboratories    | Phone: +44-117-3128165
Filton Road, Stoke Gifford      | FAX:   +44-117-3128924
Bristol BS34 8QZ, UK            | der@hplb.hpl.hp.com
Received on Monday, 8 May 2000 14:28:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:09 UTC