OASIS OSLC Lifecycle Integration for Domains (OSLC Domains) TC

Managing the development lifecycle of complex systems and software can become very difficult, especially in heterogeneous environments including homegrown tools, open source projects, and commercial tools from different vendors used by different partners and suppliers. Organizations need common vocabularies that describe similar concepts in order to effectively integrate and share information utilized in different methods and tools. Limited integration between tools and the use of different terms for the same concepts can create bottlenecks that slow continuous delivery as well as inhibit effective sharing of information for traceability, change and impact analysis.

OSLC (Open Services for Lifecycle Collaboration) is a set of related specifications that define an open technical architecture enabling tool integration that is minimalist, loosely coupled, and standardized. OSLC provides common standardized data formats and operations that apply World Wide Web and Linked Data principles, such as those defined in the W3C Linked Data Platform (LDP), to create a cohesive set of specifications that can enable products, services, and other distributed network resources to interoperate successfully.

The purpose of the OASIS OSLC Domains TC is to produce specifications that leverage the OASIS OSLC lifecycle integration Core Specification and enable interoperation through the specification of standard domain vocabularies, constraints and services for use in tools supporting change, configuration, and asset management domains supporting scenarios motived from Application Lifecycle Management (ALM), Product Lifecycle Management (PLM), Integrated Service Management (ISM), Cloud Computing, and DevOps.

This work consists of two primary activities. The first is a maintenance activity to migrate a number of existing finalized OSLC v2.0 domain specifications currently on open-services.net to OASIS. The success of OSLC in supporting lifecycle (and other) tool integrations will benefit from having all the OSLC standards managed by the same standards body, with consistent content, document format, and versioning. Since OSLC Core 3.0 is compatible with OSLC Core 2.0, and has reached Committee Specification Draft status, it is now possible to migrate the existing domain specifications to OASIS by only making document formatting changes, with no substantive changes that would introduce interoperability issues with existing implementations.

The second OASIS OSLC Domains TC activity is to capture requirements and use cases for other related domains will be used to set out the particular goals for additional vocabulary and services standardizations. A revised list of deliverables meeting these additional goals and requirements will be drafted, and design and development of new domain specifications will commence. This ensures common specification formats and coordination across related domains, while minimizing process overhead. The OASIS OSLC Domains TC may create subcommittees to address new domain specifications while providing coordination and appropriate reusable templates and content.

The OASIS OSLC Domains TC will accept as input the OSLC MS Steering Committee approved versions of the final OSLC version 2 domain specifications from open-services.net and targeted for migration to OASIS. The TC will also accept other contributions for consideration based on technical merit in so far as they conform to this charter." This is to avoid criticism that the TC is simply going to rubber stamp existing content.

The OASIS OSLC Domains TC will deliver OASIS Standards Track documents for each of these existing OSLC version 2 domain specifications as a maintenance activity including conversion of the documents to OASIS prescribed formats, but not including any substantive changes that could introduce interoperability issues with existing implementations. Candidates for migration include:

• Tracked Resource Set 2.0, Architecture Management 2.0
• Asset Management 2.0
• Automation 2.1
• Performance Monitoring 2.0
• Quality Management 2.0
• Requirements Management 2.0

The OSLC Domains TC will form a subcommittee to complete the current Product Definition 1.0 draft specification as a new OSLC Domain specification, updating the current draft to be consistent with OSLC Core 3.0 and Change and Configuration Management 1.0. In addition, The OSLC Domains TC may identify and develop other domain specifications in the course of its work.

The TC may also produce non-normative content such as usage guides, quick start documents, etc. that will assist the broader community in adopting the standard. The TC will also consider starting an OASIS Open Repository to host work associated with the TC in order to foster contributions to additional materials that supplement or support its standards work. Such additional materials could include for example, additional samples, example content, or integration test suites.

OSLC 2 domain specification migration:

For the finalized OSLC version 2 domain specifications, the OASIS OSLC Domains TC will perform essentially a maintenance activity, delivering a migration of the existing domain specifications listed above as OASIS standards track documents. Actual deliverables include:

• Tracked Resource Set 2.1
• Architecture Management 2.1
• Asset Management 2.1
• Automation 2.2
• Performance Monitoring 2.1
• Quality Management 2.1
• Requirements Management 2.1

New OSLC domain specifications:

The OASIS OSLC Domains TC is expected to produce additional standards track documents that define the vocabulary, constraints and services for new OSLC domains as specified by revised TC deliverables. For example, a Product Definition domain that defines the products delivered by development lifecycle activities. Deliveries include:

• Scenarios: these will guide the priorities and specification contents within the TC
  • Also a prioritized list of scenarios both developed by the OASIS OSLC Domains TC and contributed from OSLC User Groups, OSLC MS-affiliated TCs, Subcommittees, and the OSLC MS Steering Committee.
• Specifications: develop specifications to support the identified integration scenarios. The specifications will provide terminology and rules for defining resource vocabularies in terms of the property names and value-types and will recommend various resource representations.
  • These deliverables may constitute a collection of specifications, one per capability or a single specification covering a collection of capabilities
  • Additional specifications may be introduced over time to satisfy capabilities needed by supported scenarios
• Supporting and enabling material, produced in collaboration with other OSLC MS-affiliated TCs as appropriate or on an as-needed basis to support broad adoption including:
  • Guidance — informative, non-normative material covering topics such as implementation, resource design, and specification development
  • Best Practices — publication of various best (and worst) practices to aid in the implementation of specifications and interoperable solutions.
• Terminology: a common set of terms intended to be used across OSLC MS-affiliated TCs
• Vocabulary: in support of specifications, a set of machine and human processable vocabularies and constraints, including tools and best practices
• Test suites: provide description test suites (perhaps manual) to illustrate how implementations of specifications should comply with the specification. OASIS OSLC Domains TC may also identify suitable third party automated test suites, such as an open source suite from Eclipse Lyo, that can be used to execute such tests.

The OASIS OSLC Domains TC plans to revise and expand its specifications over time, to enable functionality called for by revisions in, and expansions of, the motivational scenarios. This means that new specifications that cover new domains may be introduced as scenarios are refined to support new terms, vocabularies and services. The TC may produce separate specifications for various domains focused areas such as for: Product Definition, Partial Update, Indexed Linked Data Provider, Reporting, Estimation and Measurement, Reconciliation and other related domains.

Maintenance

Once the TC has completed work on a specific deliverable (whether “complete” means it has become an OASIS Standard, or simply a Committee Specification is left to the TC’s discretion), the TC will provide maintenance for that deliverable. The purpose of maintenance is to provide minor revisions to previously adopted deliverables to clarify ambiguities, inconsistencies, and obvious errors. Maintenance is not intended to enhance a deliverable or to extend its functionality. In addition to maintenance, the TC may choose to create new versions of specifications that support additional capabilities as needed by scenarios.

This TC will operate under the RF (Royalty Free) on Limited Terms IPR mode as defined in the OASIS IPR Policy document.

The OASIS OSLC Domains TC will produce specifications that are applicable to two types of interest groups:

• Developers of OSLC specifications, including those produced by OSLC MS-affiliated TCs and other standards groups
• End users of Specifications, including implementers (software vendors, open source projects, and developers of custom business software)

The work should be of interest to anyone involved with integration of tools.

The OASIS OSLC Domains TC will conduct its business in English. The TC may elect to form subcommittees that produce localized documentation of the TC's work in additional languages.