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.
Each namespace may define how the XML-protocol layer should handle the request. The exact mechanism was not aggreed upon, but I propose that all that is needed is a directive that told the processor what to do with unknown namespaces.
Here are a few of the dissenting or enhancing opinions that came from the XTech2000 XML Protocol BOF:
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.
My bent on this includes an extra adapter to interface with different tranfer protocols. A given transfer/transport protocol (HTTP, SMTP, static message repository) has a transfer adapter.
As a proof of concept, I've been coding up a version running in CGI.
The problem with this model it that it implies:
Perhaps the transfer adapter can make good use of the transfer adapter where data may be pulled from the inner protocol layer. As an example:
POST http://asdf/myClass HTTP/1.1
Mandatory: (http://soap.org/schemas/method/ 23) <--- @@@ don't remember httpext syntax
23-method: add
<soap:Envelope
xmlns:soap="urn:...SOAP"
xmlns:adder="urn:...ADD">
<soap:Header>???</soap:Header>
<soap:Body>
<adder:AddRequest>
<adder:Addand>2</adder:Addand>
<adder:Addand>2</adder:Addand>
<adder:AddRequest>
</soap:Body>
<soap:Envelope>
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.
For example, SOAP may be compressed to:
POST http://asdf/myClass HTTP/1.1
<soap:Body
xmlns:soap="urn:...SOAP"
xmlns:adder="urn:...ADD">
<adder:AddRequest>
<adder:Addand>2</adder:Addand>
<adder:Addand>2</adder:Addand>
<adder:AddRequest>
</soap:Body>
without keeping a foreign observer from knowing whether it may process the data.
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?
| ext:required | kill the root node |
|---|---|
| ext:optional | ignore the element |
| ext:transparent | dive into the element |
| my:thang | application should treat as required unless it is a known enum |
Here are some other random issues that I haven't organized.
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.
Eric Prud'hommeaux,
@(#) $Id: 15-XML-protocol-Viewpoints.html,v 1.3 2000/03/20 14:31:23 eric Exp $