RE: Revision and Clarifications of some PDs (reactions to Joe Chuisano's comments)

Thanks Peter. Regarding issue #55: The reason I interpreted this as no PD 
was that the original text from our v07 spec (lines 638-639) is as 
follows:

 

"By and large, 
unstructured service descriptions do not lend themselves to be understood by a 
large audience."

 

My issue was regarding the fact that "unstructured 
service description" was not defined (even though I believe we are talking about 
a document or a Web page). The PD provided a definition of 
*structured* service description, which was not what the issue was about - 
although I agree it is good to include that definition for clarity 
purposes.

 

Suggested route to closing this issue: Clarify what is 
meant by *unstructured* service description, and follow it with "By contrast, 
structured service descriptions are..." (then include definition of structured 
data, tailored to service descriptions). 

 

Regarding a suggested definition for unstructured service description: As 
a start, a suggested definition for "unstructured data" would be: "Data 
that is not described according to an E-R model, but is rather of a more 
free-form format, such as multimedia files or unstructured text.". So a 
suggested definition for "unstructured service description" would be: "A 
service description whose format is not structured as per an E-R 
model, but is rather of a more free-form format such as a document or Web page". 

 

The only caveat here is that some would (justifiably) consider 
a document or Web page to be semi-structured rather than unstructured. So you 
may want to convey the notion of "unstructured or semi-structured service 
descriptions" instead of "unstructured service descriptions". A potential 
definition for semi-structured service descriptions would be "Service 
descriptions whose format have both structured and unstructured characteristics, 
such as a Web page or certain types of 
documents".

 

Hope that helps--

Joe

 

Joseph Chiusano

Booz Allen Hamilton

Visit us online@ http://www.boozallen.com

 

  

  
  From: Peter F Brown 
  [mailto:] 
Sent: Tuesday, June 21, 2005 7:31 
  PM
To: Chiusano Joseph
Cc: 'Don Flinn'; 
  
Subject: Revision and Clarifications of 
  some PDs (reactions to Joe Chuisano's comments)

  

  
Joe:

  
 

  
In 27, you are right: contract must specify that 
  "something" has been explicitly agreed between a set of entities. The clue to 
  the possible wording is in the PD for the previous Isuue, N° 26 "...When a 
  specific set of entities accept such a policy, a contract is usually 
  established.". I will re-word, and re-submit.

  
 

  
In 31, my intention was to allow both definitions in the 
  glossary, but I'm more or less happy with your formulation to meld them and 
  will re-submit as a revised PD;

  
 

  
In 55, there *is* a PD:

  
"Structured data: data that is described according to an 
  E-R (Entity-Relationship) model, such as data in a relational database or an 
  XML document. Structured data can be easily processed due to its organized 
  nature"...As such, I don't understand your comment: could you 
  clarify?

  
 

  
Thx, and best regards,

  
 

  
-Peter

  

  
  From: Chiusano Joseph 
  [mailto:] 
Sent: 20 June 2005 
  20:28
To: 
Subject: [soa-rm] 
  [Next Set - #29-#60) RE: [soa-rm] Feedback on Latest Issues 
  List

  

  

  
Next set (issues 29-60, 
  inclusive):

  
 

  
ISSUE 29: Concur with PD - issue 
  closed.

  
 

  

  
ISSUE 30: No specific PD 
  provided. PD simply provides a URL 
  to the new semantics section, with no further explanation given. The new 
  semantics section does not include the word "context" anywhere - so I am not 
  certain whether the text that describes context was relocated to another 
  section (and I need to verify the issue against that instance), or if it has 
  been removed from our spec altogether. Issue still 
  open.

  
 

  

  

  
ISSUE 31: 
  Do not concur with PD, 
  as it offered 2 definitions for "fabric" but did not stipulate which would be 
  placed in the glossary (and the Discovery, Presence, & Availability 
  section to which a link was provided did not include the word "fabric"). Given 
  a preference, I actually prefer the 2 definitions combined as follows: An 
  abstract concept that represents the environment in which a service resides, 
  is discovered, is invoked, and is managed, and via which messages are carried 
  between entities that interact with the service. 
  Issue still 
  open.

  
 

  
ISSUE 32: No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  

  
ISSUE 33: No specific PD 
  provided (same as Issue 30). Issue still 
  open.

  
 

  

  

  
ISSUE 34: No specific PD 
  provided (same as Issue 30). Issue still 
  open.

  
 

  

  

  
ISSUE 35: No specific PD 
  provided (same as Issue 30). Issue still 
  open.

  
 

  

  

  
ISSUE 36: No specific PD 
  provided (same as Issue 30). Issue still 
  open.

  
 

  

  

  
ISSUE 37: No specific PD 
  provided (same as Issue 30). Issue still 
  open.

  
 

  

  
ISSUE 38: No specific PD 
  provided (same as Issue 30). Issue still 
  open.

  
 

  

  
ISSUE 39: No specific PD 
  provided (same as Issue 30). Issue still 
  open.

  
 

  

  
ISSUE 40: 
  No specific PD 
  provided (same as Issue 30). Issue still 
  open.

  
 

  

  
ISSUE 41: 
  No specific PD 
  provided (same as Issue 30). Issue still 
  open.

  
 

  
ISSUE 42: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  
ISSUE 43: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  

  

  
ISSUE 44: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  
ISSUE 45: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  
ISSUE 46: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  
ISSUE 47: No PD provided at all. Issue still 
  open.

  
 

  

  
ISSUE 48: No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  
ISSUE 49: No PD provided at all. Issue still 
  open.

  
 

  

  
ISSUE 50: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  
ISSUE 51: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  
ISSUE 53: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  
ISSUE 55: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  
ISSUE 56: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  
ISSUE 57: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  
ISSUE 58: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  
ISSUE 59: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  

  
ISSUE 60: 
  No specific 
  PD provided (same as Issue 30). 
  Issue still 
  open.

  
 

  
 

  
Kind Regards,

  
Joseph Chiusano

  
Booz Allen Hamilton

  
Visit us online@ http://www.boozallen.com

  
 

  
    

    
    From: Chiusano Joseph 
    [mailto:] 
Sent: Sunday, June 19, 2005 2:33 
    PM
To: 
Subject: [soa-rm] 
    Feedback on Latest Issues List

    

    

    
Here is my 
    feedback on PDs for issues 6-28 (all mine). This is for the version sent 
    6/17, archived at http://lists.oasis-open.org/archives/soa-rm/200506/msg00167.html. 
    I will send another e-mail soon (Mon/Tues) with another group - this is all 
    I had a chance for right now.

    
 

    
Please note: My 
    stating "issue closed" or "issue still open" below is not meant to be 
    controversial - rather, it is my way of ensuring that I communciate 100% 
    clearly what I believe the status of the issue to be so that no one comes 
    back later if I have comments on text and says "you should not have stated 
    that the issue was closed". Many of the "issue still open" below are because 
    the PD stated that additional text need to be added or existing text 
    updated, but the new/updated text was not provided. My assumption here is 
    that we cannot consider an issue closed if the new/updated text is not 
    provided.

    
 

    
If our 
    procedures are such that an issue can be closed if new/updated text is not 
    provided in the PD, and the new/updated text can be commented on when it is 
    added (and a new issue created then if necessary), then please consider 
    feedback below of "Concur with PD, exact wording still pending - issue 
    still open." to mean that the issue should then be 
    closed.

    
 

    
Clear as mud? 
    For me too.;)

    
 

    
Here they 
    are:

    
 

    
ISSUE 6: Concur 
    with PD - issue closed.

    
 

    

    
ISSUE 7: 
    Recommend removing entire paragraph, which is consistent with there the PD 
    was heading (details probably not appropriate for an RM, as they are too 
    implementation-specific). This recommend should be clarified with editor 
    before closing issue.

    
 

    
ISSUE 9: Concur with PD, exact wording 
    still pending - issue still open.

    
 

    

    
ISSUE 10: Concur with PD - issue 
    closed.

    
 

    

    
ISSUE 11: PD indicates further action 
    needed on this - issue still open.

    

    
ISSUE 12: Concur with PD's suggestion 
    of referencing the definition of context provided as PD for issue #105. 
    However, may have minor comments on Issue #105's definition - will provide 
    later for Issue 105. Issue 12 is closed.

    
 

    

    
ISSUE 13: PD indicates further action 
    needed on this - issue still open.

    

    
 

    
ISSUE 14: Concur with PD, exact 
    wording still pending - issue still 
    open.

    
 

    

    
ISSUE 15: Do not concur with PD. 
    Believe we should still provide a "lighter" example that is not related to 
    supersonic jet speeds and flow dynamics, for maximum possible chance of 
    reader comprehension. Issue still open.

    
 

    

    
ISSUE 16: Concur with PD, exact 
    wording still pending - issue still 
    open.

    
 

    

    
ISSUE 17: PD refered to an invalid 
    issue # (07-01). Need proper reference - issue still 
    open.

    
 

    

    
ISSUE 18: Concur with PD, exact 
    wording still pending - issue still 
    open.

    
 

    

    
ISSUE 19: Concur 
    with PD - issue 
    closed.

    
 

    

    
ISSUE 21: Do not concur with PD, as it 
    did not not address the comment which was that we should clarify what we 
    mean by "standard, reference-able format". For example, do we mean data 
    exchange format (XML, EDI, etc.)? Do we mean a data standard that is created 
    by a community of interest (COI), regardless of whether it is expressed in 
    XML, EDI, etc. (or multiple formats)? Issue still 
    open.

    
 

    

    
ISSUE 22: Concur 
    with PD - issue closed.

    
 

    

    
ISSUE 23: Do not concur with PD, as I 
    am not certain why we are talking about resources here rather than services. 
    Perhaps we need a section on resources and their relation to services, if 
    that is pertinent for our work. Issue still 
    open.

    
 

    

    
ISSUE 26: Concur with PD, exact 
    wording at cited location in spec still pending - issue still 
    open.

    
 

    

    
ISSUE 27: Do not concur with PD 
    because do not concur with proposed definition of contract. The proposed 
    definition does not reference the fact that a contract requires 2 or more 
    parties, as it does on line 186 (Service Consumer and service). It is 
    also too close to the definition for policy. There was a link provided 
    to the most recent Semantics section, but providing this did not address the 
    original issue which was for line 186. Issue still 
    open.

    
 

    

    
ISSUE 28: Concur 
    with PD - issue 
    closed.