OASIS Open

OASIS Service Data Objects (SDO) Technical Committee

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.

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 [2] 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
   1. Their use as a source of SDO Metadata.
   2. Defining an API for their generation.
   3. Defining name mangling and package to namespace mappings.
   4. Consolidation with data objects from standard frameworks, e.g. JAX-B.
2. Service Level Programming API
   1. Define an API for performing operations that should not be part of the normal client API, such as setting the value of readOnly properties.
   2. 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
   1. Support for a concept of identity in SDO, and its relationship to other technologies.
   2. Changes to ChangeSummary representation and API.
   3. Support for partially loaded graphs. This is to prevent the entire contents of a datastore being converted to SDOs at one time.
   4. Other features requested by the DAS Specification.
4. SDO XML Path Support
   1. Clarify and extend SDO Path support.
   2. Add full support for XPath from SDO.
5. Improved XML/XSD Support
   1. Increase coverage of XSD, providing good support for all XSD features found in common industrial schemas.
   2. Provide a fallback mechanism for handling the remaining XSD corner cases.
   3. Improve tolerance for malformed XML.
   4. API to perform validation.
6. Cleaning up/ Enhancing the SDO API
   1. Improve the consistency, convenience and type safety of the API.
   2. Define standard exceptions and when they are thrown.
   3. Define a standard (type) conversion matrix.
   4. Refactor SDO into a minimal core with optional extension(s).
7. Organization of SDO Type System and Helpers
   1. Define standard ways to create HelperContexts.
   2. Define the organization and relationship between HelperContexts.
   3. Define the relationship of HelperContexts to other system entities, such as class loaders.
   4. Clarify if Type and Property objects should be DataObjects.
8. Enhancements to SDO Metadata
   1. Provide a representation of facets and other forms of metadata commonly found in practice, but which are not part of the core SDO metamodel.
   2. Support validation against the metadata, where appropriate.
   3. Provide support for versioning of types.
   4. 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.
   5. Provide a mechanism to externalize the SDO-to-XML mapping.
9. Interoperability with .NET
   1. Define interoperability with ADO .NET diffgrams.
10. Relaxing Containment Requirements
    1. Improvements to the API and metamodel to make it possible for clients to ignore containment when this is not relevant to its use case.
    2. Improvements to the API to make containment relationships easier to manage, when they are present.
11. Notification Support
    1. Define a callback mechanism to inform clients of changes to properties.
12. Programming Language Support as determined by the TC
    1. Language Specifications for Java, C++, and for all languages that are compliant with the .NET platform
    2. The TC may define additional programming language support for SDO 3.0 from the explicit list below:
       1. C
       2. COBOL
       3. PL/I
       4. JavaScript
       5. PHP
       6. Python
       7. Perl
       8. Ruby
       9. 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/

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.

The TC will operate under the RF on Limited Terms mode under the OASIS IPR Policy.

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

The TC shall conduct its proceedings in English.