[AMG] : PPT of diagram

Hi Martin, Henrik,

Using Martins version of the diagram [1,2], the difficulty I'm having is not
so much the processor N thing that Martin introduced, its the nature of the
exchange that takes place between Processor M and Handler T (particlarly if
there are a collection of handlers). I think it has different semantics that
those of the UnitData and Data operations.

I think we can resolve all of it by introducing an operation to explicitly
support intermediaries. Something like:


XMLP Application                  XMLP Application     XMLP Application
(encap of                         (encap of            (encap of
Handlers Q&R)                      Handlers @ T)        Handlers U&V)
    
XMLP_UnitData.    |             |                    |
request	      |             |                    |
----------------->|             |XMLP_Intermediary.  |
                  |             |indication          |
                  |             |------>             |
                  |             |<-----              |
                  |             |XMLP_Intermediary.  |XMLP_UnitData.
XMLP_UnitData.    |             |response            |indication
confirm           |             |                    |------>
<-----------------|             |                    |
                  |             |                    |

[Time marching down the page. All the arrows going into/out of the layer
boundary of [1,2] from above]

This preserves the end-to-end pattern of UnitData, whilst interposing the
intermediary functionality. If someone can think of a snappier name for the
operation... that would be good.

Likewise we have to handle the Data operation with intermediary support...
which would follow the same pattern. We might, just define the one operation
for intermediaries that takes a parameter that indicates whether the
operation in which it is being interposed Unitdata, the request leg of a
Data or the response leg of a Data.

Anyway, I hope this reveals what was giving me a headache... and offers a
resolution that we'll feel comfortable with.

Best regards

Stuart
PS. Does Powerpoint support Cherokee... Kanji might be a better choice :)

-----Original Message-----
From: Martin Gudgin [mailto:marting@develop.com]
Sent: 08 February 2001 22:18
To: Henrik Frystyk Nielsen; Stuart Williams
Subject: Re: PPT of diagram


I was actually thinking pretty much along the lines you state below as I was
editing the diagram. I posted it anyway but I'm pretty sure I agree with
you; it doesn't make sense because N can't 'know' what to do WRT to the XP
layer.

It was a useful exercise anyway ( for me at least ).

Gudge


P.S. Re: Danish. 3 extra characters will cope with the next diagram
iteration! Cherokee has 85 ( count them :-) ) characters, plenty to be going
on with!

P.P.S. We should probably post this exchange to dist-app



----- Original Message -----
From: "Henrik Frystyk Nielsen" <frystyk@microsoft.com>
To: "Martin Gudgin" <marting@develop.com>; "Williams, Stuart"
<skw@hplb.hpl.hp.com>
Sent: Thursday, February 08, 2001 9:26 PM
Subject: RE: PPT of diagram


> >I *think* this is close to what Stuart was wanting but I could be barking
up
> >entirely the wrong tree. Notice than XML Protocol Processor N only does
> >underlying transport mapping, no XML Protocol Block processing.
>
> I think my question then is how would processor N know what to do with
> the message? It is sort of the same question whether it makes sense to
> have processor L have no blocks. What I am concerned about is that in
> order for N to make any sense there will not only have to be "targeting"
> [10] and "processing" [11] built in (which I think is essential) but
> also "routing" [12]. Otherwise processor N wouldn't know what to do with
> the message.
>
> If routing is a required part of the XML Protocol layer then the binding
> to HTTP and other application layer protocols becomes more difficult
> because we will have to define that mapping and how it relates to the
> HTTP request-URI for example.
>
> While I think the diagram is good at explaining *how* XML Protocol fits
> in, it might not give as good an impression of what people might expect
> to get out of the work produced by this WG.
>
> In my mind, we are not going to "define" the whole diagram but rather a
> subpart that can enable other people to define the missing pieces. I
> think the necessary pieces can be limited to a single "virtual message
> hop" at each layer - I have tried to illustrate this in an update of the
> model2 revision [13][14]. Tell me what you think!
>
> >[1] http://marting.develop.com/xp/xmlprotocol-model3.ppt
> >[2] http://marting.develop.com/xp/xmlprotocol-model3.gif
> >
> >P.S. At this rate we're going to need a bigger alphabet very
> >soon, Cherokee anyone?
>
> Danish has three more characters :)
>
> Henrik
>
> [10] http://www.w3.org/2000/xp/Group/xp-reqs-05#z806
> [11] http://www.w3.org/2000/xp/Group/xp-reqs-05#z811
> [12] http://www.w3.org/2000/xp/Group/xp-reqs-05#z805
> [13] http://www.w3.org/2000/xp/Group/1/02/01-xmlprotocol-model2.gif
> [14] http://www.w3.org/2000/xp/Group/1/02/xmlprotocol-model2.ppt
>

Received on Friday, 9 February 2001 05:44:38 UTC