Re: Usage Scenarios review

 John, 
 thanks for the reply. I wasn't in the group when the
requirements were being gathered so I didn't have the full grasp
on just how close the USs must follow them and how much set the
descriptions for the USs are. But having learned this, I agree 
with most of your replies, except for what is mentioned below. 
8-)
 Generally, my comments were meant to improve the document for
better readability and educative value, a goal that seems to be
unnecessary in fact. I think we needn't spend too much additional 
time on my comments. 8-)
 

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



 >  - In S5, I think it is necessary to change the StatusResponse
 > header's meaning because it cannot conceivably contain a
 > "UNDELIVERED" or "LOST" message status, can it? I suggest to
 > remove the status and place the importance on TimeStamp, for
 > example.
 >  <jbi> I don't see a reference to UNDELIVERED or LOST in the text.
 >  If you are referring to the second bullet in the 2.5.1, then that
 >  is the text we agreed during the requirements gathering process.
 >  </jbi>

Some kind of these status codes is implied by the presence of
"DELIVERED". Otherwise the whole field would have no meaning.
I think that this usage scenario, although agreed upon during the 
req. gathering process, might be wrong in this point. IMHO it was 
agreed upon without an in-depth analysis, which I understand 
fully. Only after the analysis was done (by you creating the 
scenario solution and then by me reviewing it) I think there 
could be some kind of a feedback to the definition. 8-)

 >  - S10 should be coordinated with S6, like S6 encrypts, S10 signs.
 > Therefore I'd rename S10 to "Message header and payload dig.
 > signature".
 > <jbi> Once again, the scenario titles are part of the requirements document
 >  so I don't want to change them. I do need an example for this section.
 >  can you help ? </jbi>

I'll think of it but I can't promise you I can actually come up 
with anything suitable. I'm not familiar with XML DSIG in detail.

 >  - S21: I don't think the scenario should stream binary data in
 > one XML (SOAP) envelope. I think S21 example (and affected
 > portions of the text) should be changed to chunks of XML data so
 > that putting it into an XML envelope is understandable. Otherwise
 > I think the scenario doesn't make sense, really.
 >  <jbi> The examples in the Usage Scenario document are only one way
 >  of implementation. I'm sure that in many cases they may not be the best
 >  but gives us a tick in the box that SOAP 1.2 supports them.
 >  </jbi>

I was rather pointing out a flaw in the choice of interpretation
of this usage scenario. Streaming is OK but if we expect this
document to be ever read (which from other remarks I'm guessing
to be untrue and again, I understand it), I don't think we should
be streaming binary chunks. The only changes I suggest are to put
some XML data with "..."s in the chunks instead of the binary
stuff, that's all.

 >  - Figure 17: I think the figure might be made more complete
 > (showing the whole of the scenario S23): in the left half, make
 > the arrows point in both directions, move the oval "event
 > subscription service" in between the first two boxes. Between the
 > two halves there could be an oval "notification on an event",
 > making the right half of the figure describe the notification
 > messages.

I think the above might have been missed in my heap of comments. 
8-) At least you didn't reply. 8-)

Received on Monday, 18 March 2002 10:09:37 UTC