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


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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

Subject: FW: [oasis-charter-discuss] Proposed Charter for OASIS S-RAMP TC

We may want to discuss potential relations with this new TC under AOB on
today's call...

-----Original Message-----
From: Mary McRae [mailto:mary.mcrae@oasis-open.org] 
Sent: Wednesday, 29 September, 2010 10:09
To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org
Cc: oasis-charter-discuss@lists.oasis-open.org
Subject: [oasis-charter-discuss] Proposed Charter for OASIS S-RAMP TC

To OASIS Members:

  A draft TC charter has been submitted to establish the OASIS SOA
Repository Artifact Model and Protocol Technical Committee (below). In
accordance with the OASIS TC Process Policy section 2.2:
(http://www.oasis-open.org/committees/process-2009-07-30.php#formation) the
proposed charter is hereby submitted for comment. The comment period shall
remain open until 11:45 pm ET on 13 October 2010.

  OASIS maintains a mailing list for the purpose of submitting comments on
proposed charters. Any OASIS member may post to this list by sending email
mailto:oasis-charter-discuss@lists.oasis-open.org. All messages will be
publicly archived at:
http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who
wish to receive emails must join the group by selecting "join group" on the
group home page:
Employees of organizational members do not require primary representative
approval to subscribe to the oasis-charter-discuss e-mail.

  A telephone conference will be held among the Convener, the OASIS TC
Administrator, and those proposers who wish to attend within four days of
the close of the comment period. The announcement and call-in information
will be noted on the OASIS Charter Discuss Group Calendar.

  We encourage member comment and ask that you note the name of the proposed
TC (S-RAMP) in the subject line of your email message.



Mary P McRae
Director, Standards Development
Technical Committee Administrator
OASIS: Advancing open standards for the information society
email: mary.mcrae@oasis-open.org 
web: www.oasis-open.org
twitter: @fiberartisan #oasisopen
phone: 1.603.232.9090

Proposed Charter for Review:
OASIS SOA Repository Artifact Model and Protocol (S-RAMP) TC

(1)(a) The Name of the TC:
OASIS SOA Repository Artifact Model and Protocol (S-RAMP) Technical

(1)(b) A statement of purpose, including a definition of the problem to be

In working on a Service Oriented Architecture (SOA), organizations find it
useful to create a focal point for access to key artifacts.  These key
artifacts include data model descriptions such as XML Schema, service
interface descriptions such as WSDL, and service composition descriptions
(SCA Assembly), as well as other kinds of documents.  This focal point for
access, hereafter referred to as a SOA repository, facilitates various
activities across the life cycle of a SOA artifact, including the  design,
assembly, quality assurance, deployment and runtime operation of SOA based
applications and business processes.  The lack of a standardized information
model and interaction protocol for artifacts and their metadata residing in
a SOA repository, means that customers and vendors must build customized
access for each different vendor's SOA repository product.  This reduces
choice, flexibility and adds costs for customers when choosing tools.

The purpose of the SOA Repository Artifact Model and Protocol (S-RAMP) TC is
to define a common data model for SOA repositories as well as an interaction
protocol to facilitate the use of common tooling and sharing of data.  The
TC will define an ATOM binding which documents the syntax for interaction
with a compliant repository for create, read, update, delete and query
operations.  This approach to providing flexible access to SOA artifacts
will facilitate interoperability and provide customers with more choices of
tools that can be used to interoperate with any S-RAMP compliant SOA
repository implementation.

This TC will not prescribe how specific features should be implemented
within those SOA Repositories and tooling.  This TC is intended to define a
generic set of capabilities provided by a SOA Repository and associated SOA
Repository tooling.

(1)(c) The scope of the work of the TC:

The TC will accept as input Version 1.0 of the S-RAMP specification [1] as
published by HP, IBM, Software AG and TIBCO. The specification is divided in
to two logical modules, The Foundation and The Atom Binding.  Documents and
XML Schemas are located at 

http://s-ramp.org/downloads.html. The TC will also accept as input a list of
issues and recommended changes from the authoring companies.

Changes to the input documents or other contributions will be accepted for
consideration without any prejudice or restrictions and evaluated based on
technical merit in so far as they conform to this charter.

The scope of the TC's first set of deliverables includes further refinement
of the Input Documents, addressing issues raised by authoring companies,
incorporating appropriate additional contributions to the TC, and addressing
issues raised in the TC itself. The output of the TC is the standardization
of these documents extension points, conformance targets, capabilities and
concepts therein.  The extensibility, capabilities and concepts are
described below.

1. A core model, described using XML Schema with extension points; the
extension points will allow to extend and reuse the core model.
2. Any binding(s) that are defined should use the capabilities mentioned
below that facilitate some or all CRUD operations on the core model.  The
binding(s) will also be flexible enough to be extended to solve
implementation specific issues.

1. Create, Read, Update and Delete operations for the concepts defined below
in the concepts section.
2. Query of repository information based upon the repository's content and
metadata, including, but not limited to XPath.
3. Rendering of the Artifact Type models in a form appropriate to a binding.
4. Declaring the S-RAMP specific extensions to the Atom Publishing Protocol.
This encompasses, but is not limited to details documented in input document
describing the Atom binding.  Specifically, details about the addition,
mutation, query, and deletion of artifacts are defined here.
5. The S-RAMP Atom Binding will facilitate both a coarse-grained and
fine-grained interaction with the artifact type models described below. The
coarse-grained interaction describes how to perform CRUD operations on an
S-RAMP artifact via HTTP methods, how to create multiple artifacts via HTTP
Batch, and how to retrieve artifacts via HTTP GET. The fine-grained
interaction provides a hierarchicalrepresentation for a given class of
metadata (relationships, properties, or classifications), and provides CRUD
operations for these sections using HTTP.
6. Query of S-RAMP Artifacts and associated metadata via ATOM defined in the
S-RAMP Atom Binding. This includes use of inline queries via HTTP GET/POST
as well as use of stored queries.

1. Document Artifact - These are artifacts which correspond to physical
documents such as WSDL Documents, XML Documents, XSD Documents  and Policy
Documents which have special support in S-RAMP, however any document type
can be placed in the repository.
2. Service Implementation Model - These are special S-RAMP defined artifacts
which provide a representation of the service implementation layer
associated with the SOA Model.
3. Derived Artifact - These are artifacts which are dynamically instantiated
as a consequence of publishing a document instance whose type is one that is
supported with a Derived Model - Derived Artifacts provide a metamodel of
the content components of a particular Document Artifact.  They can not be
created or deleted directly however they can be queried and relationships to
them from other artifacts can be established. Derived Artifact models
include: Policy Model, XSD Model, WSDL Model and SOAP/WSDL Model.
4. SOA Model - These artifacts provide a conceptual representation of a SOA
environment.  A subset of The Open Group's SOA Ontology[2] is used as the
basis for the definition of these artifacts.
5. User Defined Artifact - These are artifacts defined by the user of the
S-RAMP specification and as such are out of scope.  However, the Artifact
Type models listed above must be extensible to provide for user-defined
6. Metadata, including relationships (direct associations between artifact
instances), properties (named attributes associated with an artifact
instance), and classifications (artifact decorations which reference a
classification system).

The following is a non-exhaustive list of capabilities, bindings and data
models that may  be addressed in the first deliverable, or in a subsequent
time, depending on schedule constraints. Areas where the TC work might
extend beyond the scope of the contributed documents include:
* Alternate means of query beyond XPath 1.0, such as XPath 2.0 and XQuery.
* A core model based on RDF and OWL.
* Additional metadata, including properties, relationships, and
* Additional concepts deemed essential for supporting concepts already
identified, or that are relevant to the role of a SOA Repository.
* Federation of data across multiple repositories.
* Additional bindings and data models, including REST, Web Services, BPEL,

If some function, mechanism or feature is not included in the content above,
it will be deemed to be out of scope.


Once the TC has completed work on a deliverable and it has become an OASIS
standard, the TC will enter "maintenance mode" for the deliverable.

The purpose of maintenance mode is to provide minor revisions to previously
adopted deliverables to clarify ambiguities, inconsistencies and obvious
errors. Maintenance mode is not intended to enhance a deliverable or extend
its functionality.

The TC will collect issues raised against the deliverables and periodically
process those issues. Issues that request or require new or enhanced
functionality shall be marked as enhancement requests and set aside. Issues
that result in the clarification or correction of the deliverables shall be
processed. The TC shall maintain a list of these adopted clarifications and
shall periodically create a new minor revision of the deliverables including
these updates. Periodically, but at least once a year, the TC shall produce
and vote upon a new minor revision of the deliverables.

(1)(d) A list of deliverables, with projected completion dates:
The TC has the following set of deliverables:
* S-RAMP Foundation Document specification and associated XML Schema and/or
RDF/OWL descriptions
* S-RAMP Atom Binding Document specification and associated XML Schema
and/or RDF/OWL descriptions
These two deliverables will be available end of 2011.

(1)(e) IPR Mode
The TC shall operate under RF on Limited Terms.

(1)(f) Anticipated Audience
The primary audience for the final output of this TC includes SOA Repository
architects, implementers and tooling vendors.

(1)(g) Language
The TC will use English as the language for conducting its operations.

(2) Non-normative information regarding the startup of the TC:

(2)(a) Identification of similar or applicable work that is being done in
other OASIS TCs or by other organizations:
* OASIS UDDI Specification TC. The UDDI standard describes how to store and
access service metadata in a Service Registry. It does not provide any
protocol support for storage and access of physical documents.  The SOA
Repository specification is focused on publication and query of documents
based upon their content and meta-data.
* Reusable Asset Specification (RAS). RAS files include any work products
from the software development lifecycle, such as requirements, documents,
models, source code files, deployment descriptions, test cases or scripts,
and so on.
* The following are listed as they are specifications/standards that S-RAMP
is dependent upon: (1) SOA Ontology at The Open Group; (2) Atom Syndication
Format Standard at IETF; (3) Atom Publishing Protocol Standard at IETF.

(2)(b) The date, time, and location of the first meeting, whether it  will
be held in person or by phone, and who will sponsor this first meeting.
The first TC meeting will be a face to face meeting on December 14, 2010.
(This date is approximately 75 days after submission to OASIS and 45 days
after the OASIS Member comment period closes.)

The location of the first TC meeting will be determined prior the close of
the member review period.

(2)(c) The projected on-going meeting schedule for the year following the
formation of the TC:
The S-RAMP TC will meet by telephone every other week at Time to be
determined.  The time, date and recurrence of the periodic phone call will
be confirmed at the first TC meeting.  The meetings will last no more than
two hours.  The S-RAMP TC will also hold face-to-face meetings periodically.
The date, time and place of the face-to-face meetings will be determined by
the S-RAMP TC.

(2)(d) The names, electronic mail addresses, and membership affiliations of
at least Minimum Membership who support this proposal and are committed to
the Charter and projected meeting schedule.

Chris Peltz, peltz@hp.com, Hewlett-Packard Co.
Dan Enache, denache@tibco.com, TIBCO Software Inc
Diane Jordan, drj@us.ibm.com, IBM
Eric Johnson, eric@tibco.com, TIBCO Software Inc
Gary Woods, Gary.Woods@SoftwareAG.com, Software AG
John Colgrave, colgrave@uk.ibm.com, IBM
John Favazza, john.favazza@weblayers.com, WebLayers
Jonathan Marsh, jonathan@wso2.com , WSO2
Kurt Stam, kstam@redhat.com, Red Hat
Luc Clement, luc.clement@activevos.com, Active Endpoints
Mark Little, mlittle@redhat.com, Red Hat
Martin Smithson, msmiths@uk.ibm.com, IBM
Michael Rowley, michael.rowley@activevos.com, Active Endpoints
Miroslav Novak, miroslav.novak@hp.com, Hewlett-Packard Co.
Paul Fremantle, paul@wso2.com, WSO2
Pradeep Gundavarapu, Pradeep.Gundavarapu@soa.com, SOA Software
Prasad Yendluri, Prasad.Yendluri@softwareag.com, Software AG
Radek Pospisil, radek.pospisil@hp.com, Hewlett-Packard Co.
Randall Hauch, rhauch@redhat.com, Red Hat
Steve Fanshier, Steve.Fanshier@SoftwareAG.com, Software AG
Vince Brunssen, brunssen@us.ibm.com, IBM

(2)(e) For each OASIS Organizational Member listed in (2)(d), the name,
electronic mail address, membership affiliation, and statement of support
for the proposed Charter from the Primary Representative.

David Burke, dburke@tibco.com, TIBCO Software Inc
"As TIBCO Software Inc.'s Primary Representative to OASIS, I, David Burke
(dburke@tibco.com) fully support the formation and activities of the S-RAMP
TC under the proposed charter."

Joel Fleck, joel.fleck@hp.com, Hewlett-Packard Co.
"Joel Fleck, (joel.fleck@hp.com), as Hewlett-Packard's Primary
Representative to OASIS, supports the proposed S-RAMP Charter."

Dave Ings, ings@ca.ibm.com, IBM
"As the Primary Representative to OASIS of IBM, I approve the S-RAMP

John Favazza, john.favazza@weblayers.com, WebLayers
"As the primary representative from WebLayers I fully support the S-RAMP
charter proposal."

Paul Fremantle, paul@wso2.com, WSO2
"I, Paul Fremantle, as WSO2's primary representative to OASIS, fully support
the proposed S-RAMP charter."

Mark Little, mlittle@redhat.com, Red Hat
"As Red Hat's Primary Representative to OASIS, I, Mark Little
(mlittle@redhat.com) fully support the formation and activities of the
S-RAMP TC under the proposed charter."

Prasad Yendhuri, Prasad.Yendluri@softwareag.com, Software AG
"As OASIS Primary Representative for Software AG, I
(Prasad.Yendlkuri@software.com) certify that Software AG fully supports the
formation and activities of the S-RAMP TC under the proposed charter and
agrees to be a co-proposer of the TC."

Chris Keller, chris.keller@activevos.com, Active Endpoints, Inc.
"As Active Endpoints, Inc.'s Primary Representative to OASIS, I, Christopher
Keller (chris.keller@activevos.com) support the formation and activities of
the S-RAMP TC under the proposed charter."

Alistair Farquharson, alistair.farquharson@soa.com, SOA Software
"I, Alistair Farquharson, (alistair.farquharson@soa.com), as SOA-Software's
Primary Representative to OASIS, fully support the formation and activities
of the S-RAMP TC under the proposed charter."

(2)(f) The name of the Convener who must be an Eligible Person.
Chris Peltz, Hewlett-Packard Co.

(2)(g) The name of the Member Section with which the TC intends to affiliate

(2)(h) Optionally, a list of contributions of existing technical work that
the proposers anticipate will be made to this TC.
SOA Repository Artifact Model and Protocol - The Foundation Document v1.0
and corresponding XML Schema files.
SOA Repository Artifact Model and Protocol - The Atom Binding Document v1.0
and corresponding XML Schema files.
(Available at: http://s-ramp.org/downloads.html)

(2)(h) Optionally, a draft Frequently Asked Questions (FAQ) document
regarding the planned scope of the TC, for posting on the TC's website.
Not supplied.

(2)(i) Optionally, a proposed working title and acronym for the
specification(s) to be developed by the TC.
SOA Repository Artifact Model and Protocol Standard

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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