RE: W3C plan for XML protocol work

Ken,

The ebXML specs should also be included in your listing of specifications
that define packaging specifications and headers. The ebXML strawman
packaging spec could become publicly available within two weeks. The ebXML
group is creating a "generic" set of headers that will be used for
identification, routing and packaging, but will also be used to define
processing behavior (simplex, request/response, asynchronous response, full
messaging). The latest ebXML Packaging spec can be accessed at:
http://www.xml.org/archives/ebxml-transport/msg00621.html

There is a separate document describing the ebXML headers, but it's still
under development.


Dick Brooks
http://www.8760.com/


-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Ken MacLeod
Sent: Saturday, April 22, 2000 2:37 PM
To: xml-dist-app@w3.org
Subject: Re: W3C plan for XML protocol work


Tom Harding <tomh@thinlink.com> writes:

> > We've been under pressure from many sources, including the advisory
> > board, to address the threat of fragmentation of and investigate the
> > exciting opportunities in the area of XML protocols.
>
> I took a very minimalist approach to this problem in an internet
> draft that has since expired.  There's a link to it at
> http://www.thinlink.com/xp.

Thanks for posting that.  I had a link to the XP draft but no pointer
to a lasting copy.

(nudge to Eric) I think I have a facet that helps distinguish
protocols and formats (serializations): "envelope" or "generic
envelope".

Much of what we've been calling "protocol" has been _usage_ or
_application_ of envelope format, rather than any specific definition
of an envelope format.  For example, SOAP defines a format for
specifying envelopes, and then _only_ one usage (RPC) of that format.

XP here, by implication, defines an envelope format using XML
processing instructions, and one usage (request/response) using that
format.  (Noting aside, XP does not define serialization.)

Put another way, "protocols" can be built using generic envelopes or
they can use custom envelopes -- generic XML schema or custem XML
schema for the protocol envelope.

"Extensible headers", as used in some places, is synonomous to
"generic envelope", it's a term used to (hopefully) infer that the
spec is defining a format (serialization) for headers seperate from
any particular usage of those headers (RPC/messaging).

Here's a first cut breakdown of which specs on the table define/use a
custom/fixed, generic, or don't define an envelope.  Note, any
"custom" envelope could probably be extrapolated to a generic
envelope, the label below just means that the spec didn't explicitly
do that.

  Spec                Envelope facet
  ------------------  --------------
  BizTalk             custom
  ICE                 custom
  IOTP                custom
  Jabber              custom
  LDO                 generic
  LOTP                generic
  SOAP                generic
  Userland's XML-RPC  custom
  WDDX                custom
  XP                  custom

Here's verbiage for the facet definition:

Envelope
  Defines a format for packet/message envelopes and headers.

  Custom
    Envelope+header is fixed or doesn't follow a generic serialization.

  Generic
    Envelope+header is generic/extensible and/or follows a generic
    serialization.

Note that these definitions lump two facets together, 1) generic
serialization used in header, 2) whether the values of those headers
are fixed or extensible.  For example, a complete, fixed protocol
specification that is built upon generic header and payload
specifications doesn't fit in either of these categories.

This definition of "envelope" is intended to seperate out the syntax
component of the "protocol" facet.

  -- Ken

P.S. I notice that a lot of the facets I'm describing are tending to
be enumerations (has to a degree) where Eric's have been booleans (has
or doesn't have), is this a good thing?

Received on Saturday, 22 April 2000 16:06:40 UTC