RE: [AMG]: Revised Abstract Model draft document.

Ray,
 
Firstly many thanks for you comments and observations, they are much
appreciated.  Apologies that this is quite such a long response, it contains
proposed rewording in line with your two observations and I would like your
feedback on those before I go through and do consistent alterations to the
diagrams and elsewhere in the document.
 
In relation to your second observation, you are indeed correct that your
suggestion was well received... the however, is that when I came to edit the
previous revision [1] the structure was such that I introduced the primitive
types (.request, .indication, .response and .confirm) ahead of the
operations. The .request->.indication pattern in Data and UnitData is
essentially the same, the difference really only is in the
.response->.confirm path. That would yield six descriptions where I had this
overriding feeling that there were really only four, albeit as you note, the
.confirm does have different semantics between the two operation - which is
perhaps the real difficulty here. There is  the following note about this at
the appropriate point in that revision.
 
<extract>
"Ray Dennenberg  [see
<http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Jan/0100.html>
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Jan/0100.html]
suggested renaming .request and .indication primitives as .send and .receive
for use with the UnitData operation. At present I have not done this. I did
not want to end up with 6 types of primitives instead of 4. If the group
would prefer this change, I'd be inclined to split this subsection into two
and embedded each half into the description of the relevant operation. ie.
Figure 3.2 and the description of .request, .indication, .response and
.confirm would move to be with the rest of the description of XP_DATA, and
Figure 3.3 and .send, .receive and .confirm (again) would move to be with
the rest of the description of XP_UnitData. 

Alternatively, .request and .indication could be relabelled as .send and
.receive for both Data and UnitData operations - however, .response and
.confirm would probably need to be relabelled to feel comfortable with .send
and .receive. Any suggestions?"

</extract>

In the current draft, the primitive types are not separately introduced
which makes it much more amendable to the change you suggest (although there
is of course the know on effect of checking the impact through the remainder
of the document, particular any compact references to .requests, .responses
and .confirms. I guess I'm heavily influenced by the primitive style from
the IEEE 802 LAN specs which (for me) is where  .request, .indication,
.response and .confirm come from and personally remain very comfortable with
.request, .indication and .confirm (or .status see below)  for the UnitData
operation.

So... I've tried the following in my working copy of the draft. For
XMLP_Data I've retained .request, .indication .response and .confirm and
expanded the text in Section 3.1 as follows (which I hope captures the
essense of your first observation in relation to section 3.1)

<extract>

XMLP_Data.request: Invoked by the initiating XML protocol application and
directed at the local initiating XML protocol processor to start a two-way
request/response operation.

Upon receipt of this primitive by the initiating XML protocol processor  an
XML protocol message is transferred from the initiating XML protocol
processor toward the responding XML protocol processor (possibly via
intermediary XML protocol processors).

XMLP_Data.indication: Invoked by the responding XML protocol  processor and
directed at a local responding XML protocol application to deliver the
outbound XML protocol message. 

This primitive is invoked as a result of the arrival of a XML protocol
message from the underlying protocol layers.

XMLP_Data.response: Invoked by the responding XML protocol application and
directed at the local responding XML protocol processor  to return a
response message to the initating XML protocol application.  From the
point-of-view of the responding XML application the operation has completed
once this primitive has been invoked.

Upon receipt of this primitive by the responding XML protocol processor an
XML protocol message is the transferred from the responding XML protocol
processor toward the initiating XML protocol processor (possibly via
intermediary XML protocol processors).

XMLP_Data.confirm: Invoked by the initiating XML protocol  processor and
directed at the initiating XML protocol application. 

This primitive is normally invoked to deliver the response message to the
initiating XML protocol application as a result of the arrival of an XML
protocol message from underlying protocol layers .

This primitive may also be used to inform of the failure of the operation in
those circumstances when a failure can be reported - some failures may be
silent. From the point-of-view of the initiating XML application the
operation has completed once this primitive has been invoked.

</extract>

For section 3.2 I have tried the following relabeling of the primitives (in
relation to observation 2):

XMLP_UnitData.request      -> XMLP_UnitData.send

XMLP_UnitData.indication   -> XMLP_UnitData.receive

XMLP_UnitData.confirm      -> XMLP_UnitData.status

On the UnitData.confirm I felt that both .acknowledge and .deliver also have
the potential to mislead, .status seems more in tune with what I think
happens.

Observation 1 also applies to 3.2, and 3.3 so the wording in my working copy
for the relevant portions of these sections is now:

For section 3.2:

<extract>

 XMLP_UnitData.send: Invoked by the sending XML protocol application and
directed at the local sending XML protocol processor to start a one-way
transfer operation.

Upon receipt of this primitive by the sending XML protocol processor an XML
protocol message is transferred from the sending XML protocol processor
toward the receiving XML protocol processor (possibly via intermediary XML
protocol processors).

XMLP_UnitData.receive: Invoked by the receiving XML protocol processor and
directed at  a local receiving  XML protocol application to deliver a
received XML protocol message. 

This primitive is invoked as a result of the arrival of an XML protocol
message from the underlying protocol layers.

XMLP_UnitData.status: Used to report on the delivery status of the operation
to the sending XML protocol application. This primitive may be used to
report on the success or failure to deliver a message to the receiving XML
Protocol application. In general, it is not possible to assert that a
message has been delivered to the intended recipient without engaging in
further interactions. With care it is possible to assert definite failure to
deliver provided that there is no chance of subsequent delivery. From the
point-of-view of the initiating XML application the operation has completed
once this primitive has been invoked.

</extract>

For section 3.3
 
 <extract>

XMLP_Intermediary.request: Invoked by an intermediary  XML protocol
processor and directed at a local intermediary XML protocol application to
provide the intermediary XML protocol application the opportunity to perform
intermediary processing on a message in transit.

This primitive is invoked as a result of the arrival of an XML protocol
message at an intermediary XML protocol processor from the underlying
protocol layers.

XMLP_Intermediary.resend: Invoked by an intermediary XML protocol
application once it has completed intermediary processing of a message in
transit and directed at the local intermediary XML protocol processor. The
intermediary XML protocol application may report  fatal or non-fatal failure
via the Status parameter.

A fatal error in the request leg of an XMLP_Data operation (two-way/request
response) results the premature termination of the operation and the return
of any accumulated (non-fatal errors) and partially processed XML protocol
message toward the initiating XML protocol application.

A fatal error in the response leg of an XMLP_Data operation results in the
silent failure of the operation and the loss of the response message.

Non-fatal errors during intermediary processing result in the accumulation
of faults into the XML Protocol message prior to onward transmission. In an
XML_Data operation, non-fatal faults are delivered to the responding XML
protocol application and may be propagate along the response path back to
the initiating XML protocol application.

</extract>

Best regards

Stuart

[1]
http://www.w3.org/2000/xp/Group/1/02/02-abstract-model/XMLProtocolAM.html
<http://www.w3.org/2000/xp/Group/1/02/02-abstract-model/XMLProtocolAM.html> 

 
-----Original Message-----
From: Ray Denenberg [mailto:rden@loc.gov]
Sent: 14 February 2001 22:09
To: Williams, Stuart
Cc: 'xml-dist-app@w3.org'
Subject: Re: [AMG]: Revised Abstract Model draft document.



I'm happy to see the progress on the abstract model. I  have two
observations on the latest draft. I haven't participated in the subgroup
discussions, so please pardon me if these ideas have already been considered
and rejected. 

First Observation 
----------------- 
On the definitions of the four primitives (following figure 3.1) --  I think
it is very important, for the sake of readers who don't do so well with
these abstractions, to elaborate this much more extensively. What we have
now (paraphrasing): 


XMLP_Data.request: Invoked by the initiating XML protocol application
........ 
XMLP_Data.indication: Invoked at the responding XML protocol application
....... 
XMLP_Data.response: Invoked at the responding XML protocol application .....

XMLP_Data.confirm: ......

So the application invokes the request at some entity, and  some entity
invokes the indication at the application..... 

(And as an aside: the "response" should be "by" not "at", right? But then,
that's probably a typo or an oversight, and it isn't the real problem I had
in mind; back to my point....) 


 Why not say explicitly what these (abstract) un-named entities are?   Each
system has both an XML Protocol Application (entity) and an XMLP Processor
(entity), as shown in Figure 2.1.  These primitives are each invoked by one
entity at the other entity on the same system. I'm not sure how many of you
who are sophisticated in the art of abstraction realize how difficult it is
for the uninitiated to grasp this. 


I  suggest that the following description be supplied, which illustrates
these primitives, as well as protocol actions (see steps 2 and 5), in
sequential order: 


1. XMLP_Data.request: Invoked by the initiating XML protocol application at
the initiating XMLP Processor. 

2. Protocol message from initiating XMLP Processor to responding XMLP
Processor. 


3.XMLP_Data.indication: Invoked by the responding XMLP Processor at the
responding XML protocol application. 


4. XMLP_Data.response:  Invoked by the responding XML protocol application
at the responding XMLP Processor. 


5.  Protocol message from responding XMLP Processor to the initiating XMLP
Processor.

6. XMLP_Data.confirm:  Invoked by the initiating XMLP processor at the
initiating XML Protocol application.

(Take note that I didn't use the word "entity"!) 
  

Second Observation 
--------------------- 
Although I made an earlier suggestion that I thought was well-received but
apparently was subsequently rejected, I won't belabor that because I haven't
participated actively in discussion and I'll assume there was a good reason.
I had suggested not using the names "request" and "indication" for the
one-way communication, but instead use "send" and "receive" (or "deliver"). 


However, leaving that aside, there are now three primitives: request,
indication, and confirm. I do think that calling this third primitive
"confirm" is not a good idea. Its semantics are much different from
"confirm" in the two-way case. How about calling it "acknowledge"?  Or,
alternatively, rename "confirm" in the two-way case to "deliver"  (I
actually prefer this alternative because "confirm" seems to be a more
natural name as used in the one-way case than as it is used in the two-way.)



--Ray 


-- 
Ray Denenberg 
Library of Congress 
rden@loc.gov 
202-707-5795