Re: SOAP message style

I don't think it's quite that complicated.  Nothing in the XKMS data
formats requires shared references, so everything can be inlined.  (It
can also be href/id'd up the wazoo, as your example shows, but that's
the responsibility of the SOAP layer to handle.)

In my experience, the major factors that differentiate the two styles
are "limitations" enforced by RPCEncoding:
	1.  Can't use attributes for data (just meta-data)
	2.  Repeated elements (arrays) must be wrapped in a container.

If strings or complex data (structures and arrays) are aliased, and that
aliasing is significant, then you have to use href/id.  (For example, in
C:
    char *p, *q;
    p = q = "foobar";              /* aliased */
    p = "foobar"; q = strdup(p);   /* not aliased */
SOAP RPC Encoding allows you to make the two cases above explicit.)

So, for what it's worth, my encoding of Locate would be the *exact same*
as your doc-style Locate, except adding
   <TransactionID xsi:null='1'/>

>      1) Quite a bit larger, due to additional namespaces and extensive
>      use of references

Again, they COULD be, but no semantic info is lost if not, so they NEED
NOT be. SOAP message CAN be completely typed and self-describing, but
they need not be.

>      2) Includes more information about the ‘type’ of information
>      being sent, such as the explicit nil and array type attributes.

There's a bit of a debate if "xsi:null='1'" is the same as omit; ask
Andrew Layman up in your campus. :)

>      3) Uses a more complex style based on isolating multi-reference
>      values in independent elements which are then referenced by their
>      accessors.

See #1.

>      these rules). In some cases, an array element may appear as a
>      child of its accessor, but one should be prepared to handle the
>      independent element, accessor reference style shown.

Presumably any SOAP RPC toolkit could handle this, not leaving it to
XKMS to do.  From my experience, all SOAP toolkits do the full RPC stuff
(cf http://yahoogroups.com/soapbuilders for a mail list on soap
interop).

Now then, having said all that, I believe we should use document style. 
The killer reason is that you CANNOT encode an XMLDSIG document in SOAP
RPC, so using RPCEncoding would rule out being able to consider an
XMLDSIG element as part of an XKMS protocol exchange.

>      - If we add a simple integrity and confidentiality mechanism
>      based on XML Signature and XML Encryption, we’d need to be
>      cognizant of the possible message structure(s). ...  With
>      RPC-SOAPEnc you’d want to either sign a reference to the Body
>      element or an xPath selecting all the children of Body.

Why not just sign a refernece to the Locate, as with doc-lit?

	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com

Received on Wednesday, 19 December 2001 20:10:04 UTC