Comments on the usage scenarios document

Hi Hao.

I have finally reviewed the usage scenarios document. I am not sure
what version I printed exactly as the CVS tag on my print-out says
2003/09/23. I printed it last Tuesday.

Here are some comments I noted.

- Introduction:

Maybe we should drop the classification, as I don't think that it
brings a lot, and the classification can be discussed, e.g.
reliability is listed as an MEP.

- 2.1.1 Description:

| A company (travel agent) wants to offer to people the ability

can be changed into:

  A company (travel agent) wants to offer the ability

(I probably wrote that.)

- 2.1.4 Actors & Goals:

| The travel agent tries to customer satisfaction and sell packages.

->

  The travel agent tries to customer maximize satisfaction and sell packages.

- 2.1.5 Usage scenarios:

Here it talks about orchestration. A word should probably be said
about choreography, saying that a choreography description language
can help model the whole process.

- 2.1.5.1 1. User requests availabilities about some travel dates:

Drop the "1." in the title.

- 2.1.5.1.4 Technologies / Requirements:

| Response to queries: XML documents that the travel agent service
| processes and merge together.

s/merge/merges/

- 2.1.5.4.1 Goal / Context:

| The developer has a ?(string? URL?) for an airline service

If the developer has something in her hands and wants to find
something useful, it would most probably be a URI.

- 2.2 Travel agent use case, dynamic discovery:

I had added an editors' note saying that some stuff could probably be
factorized. Here is a proposal. The following sections could refer to
the static version ones:
- 2.2.2 Scope
- 2.2.3 Stakeholders / Interests
- 2.2.4 Actors & Goals
- 2.2.5 Usage scenarios, starting at "It has to be noted that some
  additional ...", i.e. keeping the diagrams
- 2.2.5.2.3 Extensions

- 2.3.5.1.4 Technologies / Requirements:

| The usual security suspects

I would s/suspects/features/.

- 2.3.5.3.1 Goal / Context

| SmallCo thinks that it has not been paid because they did not get the
| payment advice. Well, they got it but didn't put it into their records so

I would s/Well/In fact/

- 2.3.5.3.3 Extensions

| SmallCo calls BigCo and says, "Oops. Looks OK now."

I would say:

  SmallCo notifies BigCo that everything is now in order.

- 2.3.5.4.2 Scenario / Steps:

|    3. Somebody at BigCo finally says, "Oops, we really didn't pay it".
|       BigCo initiates payment.

I would say:

  BigCo eventually notices their mistake and initiates payment.

- 3 Usage Scenarios:

We should indicate the convention used in the diagrams. It is the one
from the XMLP US document. There was an issue opened about this.

- 3.1 S001 Fire-and-forget to single receiver:

Mark-up problem. There is another 3.1: 3.1 Description. There actually
are a lot of such issues under section 3 (3.1, 3.2, 3.3, 3.4, etc.). I
am wondering if your XML is valid for the XSLT style sheet to produce
this.

I see:

| 			<div2 id="S001">
| 				<head>S001 Fire-and-forget to single receiver</head>
| 				<div3>
| 					<head>Scenario Definition</head>
| 					<p>
|           A sender wishes to send an unacknowledged message to a single receiver 
|           (e.g. send a stock price update every 15 minutes).
|           </p>
| 				</div3>
| 				
| 					<head>Description</head>

There is a "</div3><div3>" missing.

- 3.4 S004 Remote Procedure Call (RPC):

The example uses <r:GetLastTradePrice>. We should update this to
something like <r:UpdateLastTradePrice>. There was an issue opened
about us not using examples that could be easily done with an HTTP
GET.

- 3.5 WS-Arch WG Specific:

Empty. Drop.

(Notice mark-up issue here too)

- 3.13 S037 Caching with expiration:

Do we need this one when we already have S024?

- 3.14.5 Candidate Technologies:

| Sequencing aka choreography: WSCL, WSFL, XLang

In light of the Choreography WG's work, this seems wrong. I would
maybe drop the whole line.

- 3.15.4 Non-requirements:

|    1. Intermediaries. Justification: While intermediaries will be very
|       important, a first version of security would be greatly successful
|       without

I am not convinced about this. I thought that the OASIS WS secure
messaging work did address intermediaries. It needs to be removed IMO.

- 3.18 S063 Authentication:

There is no description. Drop?

- 3.19 S064 Message Integrity:

There is no description. Drop?

- 3.22 S071 Asynch/Synchronous specificity:

There isn't much in there. Drop?

At least drop the empty WS-Arch WG specific subsection.

- 3.23 S080 Transaction:

Almost empty. Drop IMO.

- 3.24 S090 Sending non-XML data:

We should probably mention here the MTOM work done by the XML Protocol Working
Group. I am currently offline so I can't give you references, but they
are on the XML Protocol WG page.

- 3.25 S091 Incremental parsing/processing of SOAP messages

I don't think that we need this one in the context of our document.

- 3.26 S092 Streaming Response:

Same comment.

- 3.28 S201 Event Management Model

It is basically empty. Drop IMO.

- 3.39 S Template:

We can drop this now.

- 4 References: 

Those need to be updated. We probably want to add a reference to the
arch document, the SOAP 1.2 Recommendations too, and maybe others.

Regards,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Monday, 19 January 2004 12:32:38 UTC