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


Help: OASIS Mailing Lists Help | MarkMail Help

tc-announce message

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

Subject: OASIS Call for Participation: Service Data Objects (SDO) TC

To:  OASIS members & interested parties

   A new OASIS technical committee is being formed. The OASIS Service Data
Objects (SDO) Technical Committee has been proposed by the members of OASIS
listed below.  The proposal, below, meets the requirements of the OASIS TC
Process [a]. The TC name, statement of purpose, scope, list of deliverables,
audience, and language specified in the proposal will constitute the TC's
official charter. Submissions of technology for consideration by the TC, and the
beginning of technical discussions, may occur no sooner than the TC's first

   This TC will operate under our 2005 IPR Policy [b]. The eligibility
requirements for becoming a participant in the TC at the first meeting (see
details below) are that:

   (a) you must be an employee of an OASIS member organization or an individual
member of OASIS;
   (b) the OASIS member must sign the OASIS membership agreement [c];
   (c) you must notify the TC chair of your intent to participate at least 15
days prior to the first meeting, which members may do by using the "Join this
TC" button on the TC's public page at [d]; and
   (d) you must attend the first meeting of the TC, at the time and date fixed

Of course, participants also may join the TC at a later time. OASIS and the TC
welcomes all interested parties.

   Non-OASIS members who wish to participate may contact us about joining OASIS
[c]. In addition, the public may access the information resources maintained for
each TC: a mail list archive, document repository and public comments facility,
which will be linked from the TC's public home page at [d].

   Please feel free to forward this announcement to any other appropriate lists.
OASIS is an open standards organization; we encourage your feedback.



Mary P McRae
Manager of TC Administration, OASIS
email: mary.mcrae@oasis-open.org  
web: www.oasis-open.org 

[a] http://www.oasis-open.org/committees/process.php
[b] http://www.oasis-open.org/who/intellectualproperty.php  
[c] See http://www.oasis-open.org/join/ 
[d] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sdo

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

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
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
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.


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:

* From the W3C, material on specification variability, test metadata &
specification clarity:

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


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

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

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-<lang> Specification for the chosen <lang> language

[1] SDO for C++ Specification V2.1

[2] SDO for C Specification. Current Draft V2.1 is available at

[3] SDO for COBOL Specification. Current Draft V2.1 is available at

[4] SDO for Java Specification V2.1.1 as produced by the JCP JSR 235
Expert Group.

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