OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issues #9-#23: My Comments


Here are my comments regarding issues #9-#23 (inclusive), as a result of matching the PD against version 7B. I will send another set shortly, beginning with issue #30.
 
Issue #9: Do not concur.
 
- Explanation: The sentence that was the basis for the comment is still there verbatim (lines 323-324). The original comment had to do with the fact that it is not entirely correct to say that a service interface "specifies how to access the service" - this can be done in documentation such as a user manual or some type of guide that instructs developers on how to programatically access services from within programming languages. The original comment recommended the following improved wording: “The service interface specifies the requirements for interacting with the service” (keep rest of sentence as-is in version 7B).
 
Issue #11: Concur.
 
Issue #13: Still open - will discuss at F2F (per Ken during this week's conference call)
 
Issue #14: Do not concur.
 
- Explanation: While an improvement over the previous version, I recommend that this wording be made clearer. Some suggestions:
 
(1) Define what is meant by "reference model terms", since this is the first time that this usage of the word "terms" is encountered in the spec. I understand that this refers to SOA-RM terminology (such as "Discovery"), but that may not be obvious to the reader,
 
(2) "to map between the SOA": Do we mean "to map between the service"? (since it is not clear *what* SOA we mean here) - meaning the service whose interface we reference on line 335
 
(3) "local service terms" - what is a "local service"? Do we mean services that are service "consumers", in which case we would map between their semantics and the semantics of an invoked service?
 
(4) It may help to provide more concrete details on what is meant by "mapping" here, perhaps with a simple example.
 
Issue #15: Do not concur.
 
- Explanation: I concur with the updated description of "Assumptions" (lines 294-296), but still believe that the example is too esoteric. In order for the reader to gain a good sense of what is meant by "assumptions" here, they need to understand what is meant by a solution "assuming a compressible or incompressible flow". Frankly, who are we trying to impress here? Why should we burden the reader with a knowledge of fluid dynamics? To make it worse, we then state that "It is not necessary here to comprehend the details of this example" - then why provide such an example?
 
Issue #16: Still open, per PD.
 
Issue #17: Still open - requires further discussion at F2F.
 
Issue #18: Concur.
 
Issue #21: Do not concur.
 
- Explanation: The original comment was regarding the need to make clearer what is meant by the term "format". The 7B update simply added (beginning on line 328) a statement that the particulars of such format are out-of-scope of the SOA-RM spec. This does not satisfy the original comment, which is to make clearer what is meant by the term "format".
 
Issue #23: Do not concur.
 
- Explanation: The original text that was cited by the comment is still in 7B, verbatim. The suggested PD (see modified wording at beginning of Section 2.1) did not change the original comment.
 
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]