[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposed Charter for OASIS Service Data Objects (SDO) Technical Committee
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-<lang> Specification for the chosen <lang> language References [1] SDO for C++ Specification V2.1 http://www.osoa.org/display/Main/Service+Data+Objects+Specifications [2] SDO for C Specification. Current Draft V2.1 is available at http://www.osoa.org/display/Main/Service+Data+Objects+Specifications [3] SDO for COBOL Specification. Current Draft V2.1 is available at http://www.osoa.org/display/Main/Service+Data+Objects+Specifications [4] SDO for Java Specification V2.1.1 as produced by the JCP JSR 235 Expert Group. http://www.jcp.org/en/jsr/detail?id=235
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]