XML Protocol Viewpoints List

The purpose of this page is to track the various viewpoints in the
XML protocol area. The statements reflected here are attributed to
people without benifit of supporting quotations from them. In other
words, these are my best guess at stating their issues. If you have
corrections or enhancements, I encourage you to contact me (Eric
Prud'hommeaux) at eric@w3.org

Before the XTech2000 XML Protocol BOF, I encountered many
folks who were interested in XML protocol standardization. I conferred
with Henrik Nielson (Microsoft), Don Box (Delovopmentor), Gopol K
(Microsoft), Glen Daniels (Allaire), Rob Weltman (Netscape), and
someone else from Netscape who's name I don't remember. We discussed a
multilayer architecture where the core consisted of a serialization
protocol and an extensibility mechanism. This example shows some
higher-level protocols stacked on the core serialization and
extensibility. This was used as a strawman to
start the BOF discussion.

Dave Winer suggested that W3C reccomend XML-RPC as an interim
standard while we sort out what we hope to produce here. XML-RPC has a
large implementation base. A W3C reccomendation would allow the
industry to implement a single protocol. A future XML-protocol
reccomendation (the product we are all working on) would then have a
clear upgrade path. This would be easier on developers than upgrading
from a variety of protocols.

When this message arrives at the server, the transfer adapter
delivers an envelope enriched by the sourceIP/port, destIP/port, and
some other stuff implicit in the HTTP connection. Perhaps the best way
to do this is to assign a namespace to the HTTP extensions and present
all the headers as HTTPns:Header="Value" attributes of the
soap:Body.

If this needs to be serialized into a contextless form, eg. to be
piped to stdout, the phat transfer adapter must store all that
information in the Header.

Glen Daniels and Noah Mendelson were concearned about making the
assumption that the protocol layer is nested above (inside of) the
serialization. Historically, it has been possible to implement RPC as
messages and messages in RPC. In an effort to determine which of these
models is closer to the true form we can examine the above
example with the RPC on the outside:

We have not adequately discussed the options here to be sure this
is not a superior architecture.

Ken and several others expressed concearns about having an option
to serialize in a simple, lean format. It is therefore important to
maintain an architecture where much of the schema and context
information may be removed for communications between parties with a
structural context. While this could mean that we boil it down to look
keep just the parameters and the values, I beleive it is more relevent
to XML if we keep enough context for a stranger to decide if it can
process the terse data. Otherwise, the transaction would probably just
be run over CGI parameter encoding.

Eric Prud'hommeaux proposes that all that is needed for
extensibility is a directive that told the processor what to do with
unknown namespaces. At the least, this would specify
required or optional. A
transparent mode would allow a processor to dive into
data that was wrapped in an envelope that the processor didn't need to
understand to process the data. An example would be an optional
signature envelope. The data inside may not be critical, or it may
have been transmitted over a secure line. Foreign directives could be
allowed in the protocol to extend the extensibility mechanism. Would
that lead to more fragmentation, or just give people to fix unexpected
requirements in the protocol?

Henry has a strong interest in formalizing the interaction between
the protocol and the transaction history. The idea is to use xinclude
to relate any message to the message immediately before it. If the
protocol is initiated by a message:

The following message relates itself to the previous message with
xinclude:

The resulting document builds a comprehensive document
without burdening the transport with redundant data.