comments on 30/3/2001 AM draft

Stuart/AM team,

Some comments on the 30/3/2001 draft [1] follow.

Cheers,

Chris

[1] http://www.w3.org/2000/xp/Group/1/03/30/XMLProtocolAbstractModel.html

1) Section 1 cites 3 operations, the intro to Section 3 cites two, yet the
primitive 'forward' seems to have been migrated to the UnitData operation,
which would seem to suggest that there is but one "operation", UnitData
with 4 primitives (send, receive, forward, and status) as defined in
section 3.1. These inconsistencies need to be addressed.


2) In section 3.1.1, the last paragraph states:
	
"Failures that arise during message processing at the recipient or at intermediary XML protocol
 applications may result in the generation of fault messages directed toward the originator of the
 message whose processing gave rise to the fault. Such fault messages are a direct consequence of
 the faulted message and this should be indicated through the use of the Correlation parameter."

However, as an intermediary may add blocks to the message, the fault may not
necessarily lie with the originator of the message, but in the intermediary
that appends the block(s) that caused the problem. Should the fault be communicated
to the intermediary that produced the block(s) at fault? Should the fault be also
propogated back to the originator of the message?


3) In section 3.1.3, the assertion that the Correlation parameter references
a message previously forwarded seems to eliminate the possibility that
a message might be related to another that takes an alternate path between
source and destination. e.g. 
	a->b->c and c->d->a

Does this mean that if a pair/set of correlated messages travels different paths
that the Correlation parameter might not apply to all nodes receiving
a message? Is the correlation applied only to messages for which there is a 
local correlary? 

4) Section 4.2 #6 says:

"SOAP:  Header entries can be referenced via links from other headers.  If they have no actor
 (targeted at the final destination), they will not be removed by any intermediaries.  Using
 that mechanism, headers can be effectively shared among modules, even at different
 nodes.  The actor-less headers are interpreted as relevant to the final processor, even
 though they may not be.  The body can only be processed by the ultimate recipient."
			  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

No where in the SOAP specification is this claim established. It is also unclear as
to what the term "processed" means. Certainly, as has been stated, the elements
of the Body element as well as the rest of the Message (or Message Package 
as defined in SMwA) are made available to a handler along with the block(s?)
that it is registered to "process".

I think that there needs to be a clear definition as to what is meant by "to process"
and that there needs to be a much clearer definition of terms (handler, block, module,
message) and what the relationships are in the abstract model.


5) Section 4.2 #7 says:

"The processing of a block may result in a fault or a successful evaluation.  A fault
 terminates processing and causes a return message containing the fault to be generated if
 a return path is available.  It is possible for a module that processes a block to have status
 information, non-fatal errors, or other results incorporated into the return value generated
 by the ultimate recipient.  It can accomplish this by inserting blocks which are targeted to
 http://.../final."

The phrase "terminates processing" needs to be qualified. Is it the processing
of the block? the module?, the message? In addition, the use of the phrase
"incorporated into the return value generated by the ultimate recipient" seems
to imply that there will be a response.


6) Section 5 references alternative bindings to HTTP and indicates that 
	"It is anticipated that others will create bindings to SMTP, TCP, SSL, 
				^^^^^^
	BEEP and others."

*who" others? Granted, this is outside of the scope of the AMG, but unless there
are standardized bindings to alternate protocols, they will be fairly useless
as regards to interoperability. At the very least, some attempt at establishing
a body that has authority to sanction standard bindings is needed IMHO.


7) Section 5 doesn't have a section defining/declaring the three binding
"operations" (OP, MSG and ERR). In addition, the disgram in section 5.1.1
only contains reference to OP and MSG (ERR is omitted). That same diagram
also refers to OP and MSG as primitives, when in fact they are Binding Operations
in the lexicon of the AM.


8) Section 5.3 still references the obsolete XMLP_Data operation


9) Something that isn't clear to me is whether the correlation discussed in section
5 is the same as correlation discussed in section 3. In fact, I believe that 
there may need to be a separation of concerns w/r/t correlation as it applies
to individual message exchange and a protocol binding which may support the
notion of session. A session may span multiple correlated message exchanges
or "conversations".


10) The other point that isn't covered adequately is the nesting of bindings, and what, if any
abstract interface exists between each of the nested bindings as well as 
that between them and the XMLP Processor Layer (e.g. to stipulate the nesting).


11) Finally, I think that there needs to be some discussion/exploration as regards
the ability for one node to communicate to another(s) what MEP (message exchange pattern)
is to be employed. In this regard, processing of a one-way messasge may be very different than
that used for a request/response pattern (e.g. RPC) carried over a synchronous 
communications protocol such as HTTP.

In fact, at the abstract layer, I do think that it is worthwhile calling out the distinction
between oneway and request/response and this needs to be (somehow) able to be
communicated through the whole stack (e.g. from the sending application through to the
receiving application). While it is quite true that one can construct the equivalent
of request/response with oneway messaging, there seems to me to be quite a bit of
information that needs to be communicated through the stack to ensure that the
pattern is correctly satisfied by the layers of software supporting the exchange.

Received on Monday, 2 April 2001 15:08:39 UTC