To OASIS Members:
A draft TC charter has been submitted to establish the Service Data
Objects (SDO) Technical Committee. In accordance with the OASIS TC
Process Policy section 2.2:
(http://www.oasis-open.org/committees/process.php#2.2) the proposed
charter is hereby submitted for comment. The comment period shall remain
open until 11:45 pm ET on 9 October 2007.
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 to:
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:
http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/.
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 (SDO) in the subject line of your email message.
Regards,
Mary
---------------------------------------------------
Mary P McRae
Manager of TC Administration, OASIS
email: mary.mcrae@oasis-open.org
web: www.oasis-open.org
phone: 603.232.9090
===========
PROPOSED CHARTER FOR REVIEW AND COMMENT
OASIS SERVICE DATA OBJECTS (SDO) TC
1. Normative information
a. Name
OASIS Service Data Objects (SDO) Technical Committee
b. Statement of Purpose
The purpose of this TC is to evolve and standardize the specifications
defining the Service Data Objects architecture and API.
Its first phase will be for SDO use with the C++ programming language. In
particular, this TC shall maintain functional equivalence with the SDO for
Java V2.1.1 Specification, under the stewardship of the Java Community
Process (JCP). This TC will continue development of the SDO for C++ V2.1
[1] specification and aim to establish it as an OASIS Standard.
In a second phase, the TC will evolve the SDO specifications (for both
Java and C++) to a Version 3.0 level of functionality. Further programming
languages may be selected from the scoped list by the TC. The TC is
encouraged to consider an effective manner of evolving SDO functionality,
keeping the multiple language specifications current and in alignment.
The two phases are not required to execute serially. The TC is encouraged
to consider a meaningful and effective overlap of work and time between
the two phases.
c. Scope
Function (V2.1.1)
Service Data Objects (SDO) is a data programming architecture and an API
whose main purpose is to simplify data programming. The key concepts,
structures and behaviours of SDO will be defined by the SDO for Java
specification [4] from the JCP and the same SDO functionality defined by
the Java specification available from C++. As far as possible, the SDO
behaviour should behave consistently across the languages while also
fitting naturally into each language’s native programming environment.
Other contributions may be made by TC members on or after the first
meeting of the TC. Such other contributions shall be considered by the TC
members on an equal basis to improve the original starting point
contribution in a manner that is compliant with this charter.
The scope for version 2.1.1 is practically limited to defect fixes and
minor corrections, as this level of functionality is already substantially
defined in the contribution documents and should therefore require only
minor corrections and updates. Any significant changes to the overall
scope and functionality of this version would be considered out-of-scope
for SDO 2.1.1 but can be addressed as part of the SDO 3.0 activity.
In general, this C++ activity of this TC is responsible for maintaining
the specification documents, taking account of:
* Additions or modifications that are made to the SDO for Java
specification under the stewardship of the JSR 235 Expert Group in the
JCP.
* Interoperability with other SDO implementations including, but not
limited, to Java.
* Natural integration into the native programming environments.
* Feedback from users.
Inevitably these will conflict to some degree, and so pragmatic
compromises will be required.
Function (V3.0)
Service Data Objects (SDO) Version 3.0 is intended to build upon the SDO
Version 2.1.1 architecture and APIs by providing additional functionality
to further simplify data programming so that developers can focus on
business logic rather than the underlying technologies. The primary
purpose of the second phase of this TC (SDO 3.0) is to build upon the
first phase of the TC by investigating the following enhancements to the
SDO 2.1.1 specifications for possible inclusion to the SDO 3.0
specifications:
1) Enhancements to Static SDO
a. Their use as a source of SDO Metadata.
b. Defining an API for their generation.
c. Defining name mangling and package to namespace mappings.
d. Consolidation with data objects from standard frameworks, e.g. JAX-B.
2) Service Level Programming API
a. Define an API for performing operations that should not be part of the
normal client API, such as setting the value of readOnly properties.
b. Allow control of the SDO runtime, to enable or disable features, for
example whether validation should be performed.
3) Features related to the Data Access Services (DAS) Specification
a. Support for a concept of identity in SDO, and its relationship to other
technologies.
b. Changes to ChangeSummary representation and API.
c. Support for partially loaded graphs. This is to prevent the entire
contents of a datastore being converted to SDOs at one time.
d. Other features requested by the DAS Specification.
4) SDO XML Path Support
a. Clarify and extend SDO Path support.
b. Add full support for XPath from SDO.
5) Improved XML/XSD Support
a. Increase coverage of XSD, providing good support for all XSD features
found in common industrial schemas.
b. Provide a fallback mechanism for handling the remaining XSD corner cases.
c. Improve tolerance for malformed XML.
d. API to perform validation.
6) Cleaning up/ Enhancing the SDO API
a. Improve the consistency, convenience and type safety of the API.
b. Define standard exceptions and when they are thrown.
c. Define a standard (type) conversion matrix.
d. Refactor SDO into a minimal core with optional extension(s).
7) Organization of SDO Type System and Helpers
a. Define standard ways to create HelperContexts.
b. Define the organization and relationship between HelperContexts.
c. Define the relationship of HelperContexts to other system entities,
such as class loaders.
d. Clarify if Type and Property objects should be DataObjects.
8) Enhancements to SDO Metadata
a. Provide a representation of facets and other forms of metadata commonly
found in practice, but which are not part of the core SDO metamodel.
b. Support validation against the metadata, where appropriate.
c. Provide support for versioning of types.
d. Provide a mechanism for identifying an ID property when defining Types
and Properties through TypeHelper. Currently ID properties can only be
derived from XML Schema nodes of type XSD:ID.
e. Provide a mechanism to externalize the SDO-to-XML mapping.
9) Interoperability with .NET
a. Define interoperability with ADO .NET diffgrams.
10) Relaxing Containment Requirements
a. Improvements to the API and metamodel to make it possible for clients
to ignore containment when this is not relevant to its use case.
b. Improvements to the API to make containment relationships easier to
manage, when they are present.
11) Notification Support
a. Define a callback mechanism to inform clients of changes to properties.
12) Programming Language Support as determined by the TC
a. Language Specifications for Java, C++, and for all languages that are
compliant with the .NET platform
b. The TC may define additional programming language support for SDO 3.0
from the explicit list below:
i. C
ii. COBOL
iii. PL/I
iv. JavaScript
v. PHP
vi. Python
vii. Perl
viii. Ruby
ix. Groovy
These functionality categories (above) provide an outline of what is
within scope for this TC. Within each of the categories there is
(considerable) latitude for additional and lower level definitions of
functionality in order to satisfy the overall objective. The TC members
shall consider these further definitions on an equal basis to improve the
specification and to ensure that the desired capability is achieved.
These considerations will be performed in a manner that is compliant with
this charter.
The sections above provide an outline of what is within scope for this TC.
In general, areas that are not explicitly listed as within the scope
should be considered as out-of-scope.
As mentioned above, the resulting specification(s) will describe the new
functionality in a language neutral manner so that a language or platform
specific implementation could be developed. As far as possible, the SDO
behaviour should behave consistently across all of the platforms while
also fitting naturally into the native programming environment.
Upwards Compatibility
To ensure that the TC will have freedom of action in defining the OASIS
standard, there are no formal requirements for upwards compatibility from
the input documents to this TC. However, every effort will be made to
ensure that clients using SDO 2.1.1 be able to upgrade to SDO 3.0 with a
minimum of effort. Consideration will be applied to any change of
feature/function that would cause incompatibility in the OASIS standard in
terms of:
* Source Code level
* Compiled Object Code
* XML data definitions
At minimum, known enhancements to the input documents that will cause
compatibility issues with early implementations in the marketplace will be
specified in a chapter in the specification, or in a separate document,
offering migration guidance.
Conformance
In line with the OASIS TC process, the TC will produce normative
conformance information describing the normative characteristics of the
specification and specific statements about what an implementation must do
to conform to the specification, and what aspects are optional (if any).
Test Suite
The TC will produce a test suite which can be used to test conformance to
the specification which will include:
1. A series of valid and invalid test cases which cover as much as is
practical of the conformance statements of the specifications produced by
this TC, with a description of each of the artifacts involved, constraints
on the environment, the test case characteristics and their expected
behavior. The artifacts should include example SDO implementations used to
drive the test cases.
2. With the exception of necessary SDO implementation test artifacts, the
provided artifacts should be independent of implementation language and
binding type, and show clear mappings which allow the provision of
suitable concrete implementations and concrete binding type, with any
required policies.
The Test Suite shall be packaged separately from the specifications
produced by the TC.
The TC shall develop the test suite in collaboration with other TCs within
the Open-CSA Member Section.
The following material should be considered as best practice for the
preparation of conformance and test suite materials:
* From OASIS: material on specification conformance statements:
http://www.oasis-open.org/committees/download.php/305/conformance_requirements-v1.pdf
* From the W3C, material on specification variability, test metadata &
specification clarity:
http://www.w3.org/TR/2005/NOTE-spec-variability-20050831/
http://www.w3.org/TR/2005/NOTE-test-metadata-20050914/
http://www.w3.org/TR/qaframe-spec/
d. Deliverables
The TC has the following set of deliverables for the first phase
(anticipated delivery time of 6 months):
* A revised V2.1.1 specification for SDO for C++, including corrections
and essential revisions to the existing OSOA specification [1],
* A Conformance Test Suite for the above C++ specification.
The TC may decide to re-structure the starting point document [1] to
produce a larger number of distinct documents (for example to support
multiple languages) or it may decide to merge with other specifications to
produce fewer distinct documents. The TC may decide to change the names of
the documents included in the starting point contribution.
The TC has the following set of deliverables for the second phase
(anticipated delivery time of 15-18 months):
* A V3.0 specification for SDO for Java, including enhancements,
corrections, essential revisions to the V2.1.1 specification,
* A Conformance Test Suite for the above Java specification,
* A V3.0 specification for SDO for C++, including enhancements,
corrections and essential revisions to the V2.1.1 specification,
* A Conformance Test Suite for the above C++ specification.
* A V3.0 specification for SDO for the .NET platform,
* A Conformance Test Suite for the above .NET specification.
Should the TC determine to support additional languages, the following
would be required for each language:
* A V3.0 level specification for the native programming language. If
there is a prior version of this language specification developed either
via this TC or the OSOA collaboration, the new specification should
include corrections, essential revisions and updates from the previous
specification,
* A Conformance Test Suite for the native programming environment.
Exit Criteria
The TC shall define concrete exit criteria for each project that include
at least two independent offerings that implement and are compliant with
the all normative portions of specifications and demonstrate
interoperability and portability as appropriate. Note that these are
minimums and that the TC is free to set more stringent criteria.
Maintenance
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.
e. IPR Mode
The TC will operate under the RF on Limited Terms mode under the OASIS IPR
Policy.
f. Anticipated audience
The anticipated audience for this work includes:
* Vendors offering products designed to support applications using a
service-oriented architecture.
* Other specification authors that need a data programming API.
* Software architects and programmers, who design, write, integrate and
deploy applications using a service-oriented architecture.
* Vendors making products used to integrate applications and services such
as ESBs
g. Language
The TC shall conduct its proceedings in English.
2. Non-normative information regarding the startup of the TC
a. Related and similar work
The SDO specifications are intended to encompass a range of technologies
which are useful in implementing service-oriented solutions. These
include the range of Data related specifications such as SQL and
Relational Data. The list is extensive and there is no limit to the
relevance of these specifications to SDO. SDO does not intend to replace
these specifications, but to build upon them.
Other existing technologies such as Java Enterprise Edition also have a
relationship to SDO and SDO anticipates optionally using these in relevant
parts of the specifications.
The TC anticipates accepting completed work from the Java Community
Process (JSR 235 - SDO V2.1.1 for Java) and the OSOA Collaboration (SDO
V2.1 for C++, C and COBOL) as input documents to its work. The work of the
TC will complement independent work being carried out in the specification
of Data Access Service (DAS).
The TC anticipates potential complementary work with the SCA Technical
Committees already under way in OASIS. This will be achieved by normal
inter-TC liaison mechanisms, following guidelines laid down by OASIS
and/or the Member Section with which it seeks affiliation.
b. Proposed date, time, and location of first TC meeting
The initial teleconference will be held on November 29th, 2007 at 11.30
EDT / 16.30 BST / 17.30 CET.
IBM will sponsor the teleconference.
c. On-going schedule
It is anticipated that the committee will hold weekly teleconferences at a
time, day and call-in number to be agreed at the initial teleconference.
It is anticipated that the committee will meet face-to-face once every
quarter at a date and venue to be decided by the TC, but with a commitment
to hold meetings in different regions of the world so as to share the
effort of travel.
d. Supporters:
The following eligible individuals are in support of this proposal:
Radu Preotiuc-Pietro, BEA, radu.preotiuc-pietro@bea.com
Mike Edwards, IBM, mike_edwards@uk.ibm.com
Shawn Moe, IBM, smoe@us.ibm.com
Bryan Aupperle, IBM aupperle@us.ibm.com
Frank Budinsky, IBM, frankb@ca.ibm.com
Graham Barber, IBM, graham_barber@uk.ibm.com
Blaise Doughan, Oracle, blaise.doughan@oracle.com
David Ritter, Rogue Wave, ritter@roguewave.com
Michael Yoder, Rogue Wave, yoder@roguewave.com
Ron Barack, SAP, ron.barack@sap.com
Henning Blohm, SAP, henning.blohm@sap.com
Matthew Adams, Xcalia, matthew.adams@xcalia.com
Eric Samson, Xcalia, eric.samson@xcalia.com
Christophe Boutard, Xcalia, christophe.boutard@xcalia.com
Francois Huaulme, Xcalia, francois.huaulme@xcalia.com
e. Convener:
Shawn Moe, IBM, smoe@us.ibm.com
f. Name of Member Section to which this TC is affiliated
Subject to the agreement of the Member Section Steering Committee, this TC
will affiliate with the Open CSA Member Section as it commences work.
g. Anticipated contributions
It is expected that the existing SDO for C++ Specification Version 2.1 as
published in December 2006 will be a contribution from the Open SOA
Collaboration [1].
It is expected that the existing SDO for C Specification Version 2.1, when
published, will be a contribution from the Open SOA Collaboration [2].
It is expected that the existing SDO for COBOL Specification Version 2.1,
when published, will be a contribution from the Open SOA Collaboration
[3].
It is expected that the existing SDO for Java Specification Version 2.1.1,
when published, will be a contribution from the leaders of the JCP Expert
Group for JSR 235 [4].
h. Draft FAQ Document
Intentionally left empty.
i. Proposed working title(s)
SDO-J Specification
SDO-C++ Specification
SDO-.NET Specification
SDO-