This is referenced to the email to oasis-charter-discuss of 24 August
2009
(http://lists.oasis-open.org/archives/oasis-charter-discuss/200908/msg00001.html
).
Due to time pressures related to another charter that I'm working on, I
apologize in advance for my limited time for these comments. Please
contact me if you have any questions or would like additional
suggestions.
These comments are made by an OASIS Technical Advisory Board member.
(1) The format is unusual, but (except for missing items listed below)
seems reasonably complete. Commonly people use the section
number/letters as called out in the TC Process.
(2) The Scope is generally very clear, with some specific issues listed
in the next several items.
(3) The Scope should be more self contained, e.g., reference is made to
the "Statement of Purpose" (section (1)(b)). Saying that "The scope of
the effort will be guided by the above Statement of Purpose" is
confusing and unacceptable in a TC Charter. Remove this reference.
(4) The Scope references a number of documents on xml.coverpages.org..
This is a serious problem for several reasons:
(a) It is not clear that the URIs will persist.
(b) Referenced documents are copyright CA, IBM, and Fujitsu
2008-2009. Since these documents are copyrighted, they should be
referenced in section (2)(h), not in Part One of the submitted charter.
A statement that they are anticipated to be contributed is appropriate.
These should be deleted from the Scope.
(c) The medical terminology [actually biological terminology],
while evocative, is not addressed in the charter. The FAQ document on
the same server at http://xml.coverpages.org/SAF/
(http://xml.coverpages.org/SAF/SAF-FAQ-01.doc) would explain this
mystery. See later item -- should be in Section (2)(i)
(d) "The TC shall consider and work with other standards
organizations, as agreed to by a majority of its members." does not
belong here, it belongs in Section (2)(a). This is a statement related
to the TC process and is, I believe, inappropriate in Section 1 of a
charter. If there is other specific work, list it in (2)(a) where it is
required; if there is none, this is an empty statement -- and with
rewording could fit into Section 2 (e..g., "The TC explicitly will not
duplicate existing work. Accordingly, the TC expects to work with other
standards organizations and to normatively reference other standards
work."
(5) I appreciate and admire the clarity of the "out of scope" section.
(6) Near the end of the scope section: "The TC will not attempt to
define functionality duplicating that of any normatively referenced
specification in the input specifications." --This is overly narrow and
troubling. A clear statement that the TC does not intend to
substantially duplicate existing work is broader and better (and
removes a lot of objections).. Moreeover, the linked SAF-Spec-V10.doc
has NO NORMATIVE REFERENCES except for RFC2119, XPath, and XML. This is
disengenuous at best, and must be addressed.
(7) Elsewhere the charter says that "The output specifications will
uphold the basic principles of other Web services specifications in
terms of independence, composition, and composability with the other
specifications in the Web services architecture, such as the
specifications listed in the References section". This in itself is
inadequate, as the only items listed in the References are XML Schema.
This should be replaced with a broader list, or reworded to say what is
meant. "the Web services architecture" is not specific. Any spec with
"WS" in the title? Any spec that conforms to the SOA reference model?
and so forth. I'd suggest rewording to make more clear, and to
eliminate a pointer to the "references section" as that is for the
charter as a whole--only Section 1 is on the TC web page after it's
formed.
(8) Maintenance mode wording is VERY confusing. Under "Maintenance":
"Once the TC has completed work on a deliverable and it has become an
OASIS standard..." which talks about minor clarifying revisions. But
two paragraphs earlier, "Ratification of the above specifications as
OASIS standards, including a brief period to address any errata will
mark the end of the TC's lifecycle. The TC may decide to recharter when
complete to continue maintenance activities on an ongoing basis or to
create further substantive improvements in the specifications rather
than permanently disband." These are NOT CONSISTENT without twisting
the words. State what you mean, and make it consistent. Some TCs do a
maintenance mode to continue work (including potentially new versions);
others terminate when they complete their charter. You've mixed the
two; this must be consistent and reflect the thoughts of the submitters.
(9) Exit Criteria: The last sentence is redundant, and does not
clarify. Delete it.
(10) Ongoing TC Work: I'm not sure what this adds? I suggest that you
delete this paragraph and heading. Note that this is under Section
(1)(d) per the TC process and doesn't belong here as it's method of
work -- but nearly all TCs do this anyway.
(11) Section (1)(d) of the charter per the TC process is "List of
Deliverables." "Ongoing TC Work" doesn't belong (and should be deleted
per previous comment); "Exit Criteria" is more problematic, as it's a
method of work. I don't object, but some might.
(12) Section (1)(f) Audience: This is confusing because of the
self-reference "...autonomic computing..."Symptoms.." -- You've defined
(roughly) Symptoms; is autonomic computing more than what's in the TC
charter?
(13) Identification of Similar Works: (Section (2)(a)). There's really
nothing relevant? This is a green field? The cloud computing,
enterprise management, and optimization of business processes areas are
certainly relevant. I submit that this is not a totally new area, with
no similar or related work. Per the TC process, this section should
cover "similar or applicable work". The fact that there is no breadth
of description is not acceptable in a charter.
(14) Similar work in OASIS includes SOA-EERP TC (SOA deployment
optimization) which addresses "automatic resolution or optimization of
business processes and environments..." per your Audience statement.
Your whitepaper mentions connections and relationships with SOA,
software as a service, and cloud computing. This suggests a broader
range of applicable and related work, perhaps including in addition to
OASIS SOA-EERP, OASIS SOA-RM and SOA-RA; I would also consider a
reference to the OMG work that you dismiss.
(15) Missing Sections: Per the OASIS TC Process, the following
sections are missing:
(2)(e) (I believe that this does not apply to this charter, as it
was submitted before September 1, 2009 when this rule went into effect).
(2)(h) A list of contributions of existing technical work that the
proposers anticipate will be made to this TC". This is where the
descriptions and links and titles of documents belongs, not in Section
1. Since employees of the relevant companies stating copyright are on
the TC charter as convener or supporter, this should present little
difficulty. And without it, what are you starting with in your
aggressive schedule?
(2)(i) The medical terminology [actually biological terminology],
while evocative, is not addressed in the
charter. The FAQ document on the same server at
http://xml.coverpages.org/SAF/
(http://xml.coverpages.org/SAF/SAF-FAQ-01.doc) would explain this
mystery. See later item -- INCLUDE THE FAQ DOCUMENT TEXT in Section
(2)(i). The motivation of the terminology is important, and could be
included in the FAQ or a greatly expanded section (2)(a) per earlier
comments.
(2)(j) Proposed working title and acronym for the
specifications...This is apparently "SAF", but if so should be stated
in a new section (2)(j).
(16) Clarify the following sections:
(2)(g): Conventional wording is "The TC does not intend to
affiliate with any OASIS Member Section [at this time]."
OASIS Technical Advisory Board Member
bill cox