[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Tomorrow's meeting
Our public review was from 5 June 2006 to 20 June 2006. This specification was previously submitted for a 60-day public review on 13 February, 2006[1]; the 15-day review is limited in scope to changes made from the previous review. Both the PDF and HTML versions incorporate change marks. We have received some comments but most of the email archived on the comments list is spam advertising drugs, ringtones and other "vitamins". The page of all archived comments is at: http://lists.oasis-open.org/archives/soa-rm-comment/200606/maillist.html There are 4 comments that appear legitimate and we now have to triage the list. Here is an initial list. We will discuss on the call tomorrow. ************************************************************************ * URL: http://lists.oasis-open.org/archives/soa-rm-comment/200606/msg00015.html June 17 omment from: marbux@gmail.com Name: Marbux Title: None Organization: None Regarding Specification: Second Draft Reference Model for Service Oriented Architecture v1.0 Dear TC participants: I have attempted to review the draft from the viewpoint of a layman. My comments reflect that viewpoint. Lines 246-247. This new material presumes too much knowledge by laymen on the topic of Object Oriented Programming. SOA has been well explained earlier in the draft, complete with examples. However, fundamental relevant concepts of OOP are not explained, and the explanation of an "object" and its role is far too cursory; e.g., "packaging data with operations" and "melding of methods to a given data object." The distinction drawn between the OOP and SOA paradigms is sufficiently explained for a developer to understand. But for a document that is intended to be understandable to laymen as well, a better explanation of OOP and easily recognizable examples of an "object" would be helpful. It should not be assumed that a layman is familiar with those terms. Lines 344-345 contains a clause that likewise assumes too much knowledge on the part of the lay reader. "without the proper libraries being present the function call cannot complete." Laymen rarely know what a "library" is in the sense the term is used by programmers; a "function call" is another term of art not known to laymen. I could provide more examples if it would be helpful. But I think it would be far more helpful if the TC could arrange to have a layman with good editing skills but no programming experience whatsoever supervise a complete rewrite. I support the TC's goal of making the document informative for both software developers and laymen. But the document has not succeeded in delivering a product that is useful to laymen. But I still appreciated reading it very much. It did help me understand more of the relevant concepts. ****************************************************** URL: http://lists.oasis-open.org/archives/soa-rm-comment/200606/msg00006.html June 7, 2006 Comment from: fzhu@mitre.org Name: Dr. Frank Zhu Title: Sr. System Engineer Organization: MITRE Regarding Specification: SOA-RM (policy and contracts) --- policy is going to play very important role in SOA. SOA service first has to be policy oriented, which means that policy has to be involved from the full life cycle of SOA service development from development to runtime. Therefore it should be beneficial to develop SOA policy reference model in which it could define capabilities, policy information model, policy language/computing, etc. The current version of SOA rm on policy is little vague. If Users can derive concerete product from SOA policy refence model, it would be great. ******************************************************* URL: http://lists.oasis-open.org/archives/soa-rm-comment/200606/msg00003.html June 5 Comment from: Sean.barker@baesystems.com Name:Sean Barker Title:Scientist Organization:BAE SYSTEMS Regarding Specification:Reference Model for Service Oriented Architecture 1.0 Re Section 3.2.2.1.2 Semantics, line 457, 458. The claim that "The formal descriptions of terms and the relationships between them (e.g., an ontology) provides a firm basis for selecting correct interpretations for elements of information exchanged" is incomplete, in that for applications that have an effect on the real world, the formal description must be based on the behaviour of the organizations - that is, at least some form of process model - and not simply on the descriptions of the terms themselves. A clarification of what constitutes a formal description in this context would be helpful. ******************************************************** ******************************* Adobe Systems, Inc. - http://www.adobe.com Adobe Developer Program - http://developer.adobe.com/ Chair - OASIS SOA Reference Model Technical Committee Personal Blog - http://technoracle.blogspot.com/ *******************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]