- From: Ken MacLeod <ken@bitsko.slc.ut.us>
- Date: 18 Apr 2000 09:34:24 -0500
- To: xml-dist-app@w3.org
"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>
Received on Tuesday, 18 April 2000 10:30:52 UTC