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

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

From: Eric Prud'hommeaux <eric@w3.org>
Date: Mon, 8 May 2000 14:52:42 -0400
To: Dave Reynolds <der@hplb.hpl.hp.com>
Cc: xml-dist-app@w3.org
Message-ID: <20000508145241.J27982@w3.org>
On Mon, May 08, 2000 at 05:00:59PM +0100, Dave Reynolds wrote:
> 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.
> 
> So:
> 1. Is this a reasonable sort of requirement? Am I just unusual in even
> trying to do this!

I beleive the danger lies in making object model constraints on or
assumptions about the underlying protocol. SOAP doesn't make any
assertions lie within its header and body elements so one may
encapsulate some XHTML without it tromping a prescripted document
structure. If we tried to do this over XML-RPC, we would get a parse
error because <head> isn't a primitive type.

This argument seems to favor less structured (regions in)
serialization schemes, however, I think that there may be a lot to be
gained from more structured (ie. structure that is understood by the
core protocol) serialization. In this case, you would need a marker
(like embedded-xml) to signal protocol-level parsers to treat the tree
underneath as a literal string.

> 2. Is there some capability along these lines already available or
> planned?

RDF has this capability
[http://www.w3.org/TR/REC-rdf-syntax/#parseLiteral] and I find it
mostly used as a fancy string. For instance, from a trivial
annotation (look down 22 lines):

<r:RDF
 xmlns:d="http://purl.org/dc/elements/1.0/"
 xmlns:xlink="http://www.w3.org/1999/xx/xlink#"
 xmlns:http="http://www.w3.org/1999/xx/http#"
 xmlns:a="http://www.w3.org/1999/xx/annotation-ns#"
 xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
   <r:Description
    about="http://quake.w3.org/CGI/annotate?annotation=/2000/05/08-18:04:55">
      <r:type
       resource="http://www.w3.org/1999/xx/annotation-ns#Annotation" />
      <a:annotates
       r:resource="http://slow1.w3.org/2000/03/29-XML-protocol-matrix" />
      <a:context>#(1|2)</a:context>
      <d:creator>John Smith</d:creator>
      <a:created>Jan 1 1970</a:created>
      <d:date>Jan 2 1970</d:date>
      <a:body>
         <r:Description
          about="http://quake.w3.org/CGI/annotate?body=/2000/05/08-18:04:55">
            <http:Body
             r:parseType="Literal"><html>
 <head>
  <title>interjection</title>
 </head>
 <body>
     <tr><td><a name="compare.LOTP" href="http://www.w3.org/2000/03/31-LOTP-Architecture">LOTP</a></td><td colspan="8">not reviewed yet</td></tr>
 </body>
</html></http:Body>
            <http:ContentType>text/html</http:ContentType>
            <http:ContentLength>224</http:ContentLength>
         </r:Description>
      </a:body>
   </r:Description>
</r:RDF>
-- 
-eric

(eric@w3.org)
Received on Monday, 8 May 2000 14:53:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:56 GMT