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

 


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-charter-discuss message

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


Subject: Re: Comments on Charter for OASIS Symptoms Autonomic Framework (SAF)TC


Clarification:

Item (1) - The section numbers are stripped off in the publication process. The relationship between the mandated sections and the ones supplied is still confusing.

Due to other commitments ending at 12:30pm EDT Thursday I will likely not be able to attend the convener call (or will be late if I can).

Thanks!

bill
--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax


William Cox wrote:
4AA5C978.1010504@CoxSoftwareArchitects.com" type="cite">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
--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax


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