Re: [AMG]: Glossary terms: XP Processor, XP Sender and XP Receiver.

I don't like Fig 4 of the reqt document [1].

I would like to think of the XP processor as the set of XP-layer-entities, 
which must include XP-Core and zero or more XP-modules.
I like the notion of an XP-user for the layer above the XP-layer.
I am not comfortable with an XP Processing Intermediary being an XP-user.
If we accept the encapsulation model described in section 6.2 [1], then I 
see an XP-user being concerned primarity with the XP body.  An XP 
Processing Intermediary, as I see it, is concerned with the XP Header; it 
may examine XP Blocks within the XP header and possibly add XP Blocks to 
the XP Header.  I envision XP Modules adding XP blocks into the XP header 
which are digital signatures of XP blocks located in the XP Body (or XP 
Header or possibly signatures of things outside the XP envelope, such as, 
an image carried as a separate MIME part).

I think of an XP Sender as being part of the XP-layer, since an XP 
Processing Intermediary, in my view, would not be an XP-user for reasons 
stated above.

The XP-User passes the XP Body and other information (what OSI called 
Interface Control Information (ICI)) down to the Initial XP Sender.  The 
"other information" would be used by the XP-Layer to construct portions of 
the XP Header.

I like Fig 3 [1], but to be consistent with my view of life, there should 
be a box above the Initial XP Sender with the label "Initiating XP 
User".  Likewise, add a box above the Ultimate XP Receiver with the label 
"Target XP User".  I'm not sure how to handle the RPC case.  Since the RPC 
reply or response is an XP message (albeit with some info tying to the 
request), the Initiating XP User would be the "Called XP User" and the 
Target XP User would be the "Calling XP User".  For the RPC request, the 
Initiating XP User would be the Calling XP User, and the Target XP User 
would be the Called XP User.

I'm thinking we need separate terms for the case where the interchange is 
more elaborate than RPC, for example, the ongoing exchange of information 
for a business transaction as addressed by DS8 [3].  For such as exchange, 
there may be many Initiating XP Users and Target XP Users, but they would 
not necessarily be Calling and Called XP Users.  We may want to consider 
defining other ??-XP-Users for such exchanges, where each can take on the 
role of Initiating or Target XP User.  I believe ebXML is looking at ways 
to specify such exchanges [4].

[3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0081.html
[4] http://lists.ebxml.org/archives/ebxml-bp/200101/msg00068.html

Paul

At 06:14 AM 2001-02-01, Williams, Stuart wrote:
>Folks,
>
>I'm trying to reconcile the terms, "XP Client" and "XP Layer entity" that I
>used in the strawman [2], with terms and diagrams for "XP Processor", "XP
>sender" and "XP receiver" from the requirements document [1].
>
>I think that the narrative of the glossary and Figure 4 present an
>inconsistent view. I prefer the implied by Fig 4 and would like to see the
>narrative adjusted to be more consistent with Fig 4.
>
>Figure 4 from [1] suggests a match between "XP processor" and "XP client"
>which feels comfortable to me. It makes the "XP Processor" an 'application'
>entity that handles application processing of an XP message once it has been
>received and forms application messages to be send.
>
>The "XP sender" and "XP receiver" of figure 4 are then the entities that
>actually deal with the rules of the protocol and the transfer of the message
>over the 'wire' through the use of underlying protocols. That makes "XP
>sender" and "XP receiver" from [1] match with "XP layer entity" from [2] and
>really specialise it to the role of sending or receiving an XP message.
>
>However, the text of the glosssary entries, suggests completely the
>converse:
>
><extract>
>XP processor
>An XP Processor processes an XP message according to the formal set of
>conventions defined by the XML Protocol and generates an XP fault if the
>conventions are not followed. Insufficient or wrong data carried in an XP
>block can cause an XP processor to generate a fault (see also XP receiver
>and XP sender)
>
>XP sender
>An application that can generate an XP message and perform an XP binding to
>a specific protocol for the purpose of transmitting the message.
>
>XP receiver
>An application that can accept an incoming XP message transmitted using some
>XP binding, extract the message from the XP binding and pass the message to
>an XP processor.
></extract>
>
>The text yields match between "XP layer entity" and "XP processor" and
>places "XP sender" and "XP receiver" as applications which for me matches up
>with my notion of an "XP Client".
>
>Thoughts, Comments?
>
>Stuart
>
>[1] http://www.w3.org/TR/2000/WD-xp-reqs-20001219/
>[2] http://www.w3.org/2000/xp/Group/1/01/15-abstract-model/

Received on Thursday, 1 February 2001 12:12:37 UTC