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