Tomorrow's meeting

["Duane Nickull" <dnickull@adobe.com>]

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/
*******************************