"Eric Prud'hommeaux" <eric@w3.org> writes:
> On Mon, Apr 17, 2000 at 07:51:15AM -0500, Ken MacLeod wrote:
> > I think we can clearly seperate serialization (a la SOAP Section 8)
> > from most other aspects (messaging and transport, specifically).
> >
> > I think a serialization format can and should be discussed in its own
> > forum, track, and/or working group. The other aspects are a much
> > larger problem space.
>
> If we devote some time and attention to the general architecture, we
> can get a clear picture of what the pieces need from each
> other. [...] Do you have some time to draw up a doc describing the
> goals of these sepparate groups?
The only group (I think) that is immediately clear is serialization.
At least a handful of the specs on the table have serialization
seperate from messaging, envelope, or RPC (even if the specs
themselves don't make that distinction). Serialization, alone, is
worthwhile, and many of the specs on the table encode their other
aspects (like envelope and headers) _in_ the serialization format.
All the other aspects are more widely different among the specs on the
table. Here are some possible groups:
Transport
Transport negotiation
Envelope+header format
Envelope+header usage (i.e. messaging, RPC, transfer)
Protocol negotiation/features
Interface discovery
Schemas/object definition
> However, I doubt it is yet time to have sepperate groups looking at
> serialization and RPC. Also, I'm not convinced that serialization
> would be specified in a sepparate document from messaging. The two
> seem to rely on each other pretty intimately. It is easy to imaging
> stacking an RPC protocol on top of a standard message format without
> having the message format require anything of the RPC protocol. I'm
> having a harder time drawing such a line between messaging and
> serialization.
[your alternating use of RPC and messaging here is confusing]
The following specs on the table have clear seperations of
serialization and messaging/RPC (even if they don't make that
distinction themselves):
BizTalk[1] content of <Body>
LDO[2] LDO-XML
LOTP[3] content of <Body>
SOAP[4] section 8, content of <Body>
Userland's XML-RPC[5] content of <param>
WDDX[6] content of <data>
ICE[7], IOTP[8], and Jabber[9] define a specific DTD/schema that could
be encoded using standard serialization rules.
Wf-XML[10] and ebXML[11] don't appear to define their own serialization
(content of <WfMessageBody> for Wf-XML, the "document" in ebXML).
Note, in all cases, the envelope and header elements of any spec could
(and should, IMO) follow standard serialization rules.
In conclusion, I'll repeat my assertion that serialization is a
clearly seperate layer that easily seperable from the other aspects of
XML protocols. Several of the protocol envelopes even allow alternate
serializations to be used, either as an extension or a standard
feature.
-- Ken
[1] <http://www.biztalk.org/Resources/frame081.asp>
[2] <http://Casbah.org/Scarab/xml-serialization.html>
[3] <http://www.w3.org/2000/03/31-LOTP-Architecture>
[4] <http://www.msdn.microsoft.com/xml/general/soapspec-v1.asp>
[5] <http://www.xmlrpc.com/spec/>
[6] <http://wddx.org/DTD.htm>
[7] <http://www.idealliance.org/ice/ice_note-ice-19990519.htm>
[8] <http://search.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-07.txt>
[9] <http://protocol.jabber.org/docs/messages.html>
[10] <http://www.aiim.org/wfmc/standards/docs/tc1023v10beta.pdf>
[11] <http://www.ebxml.org/specdrafts/transportation/trpreq.pdf>