OASIS members & interested parties,
A new OASIS technical committee is being formed. The OASIS Variability Exchange Language (VEL) Technical Committee (TC) has been proposed by the members of OASIS listed in the charter below. The TC name, statement of purpose, scope, list of deliverables, audience, IPR mode and language specified in this 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 meeting.
The eligibility requirements for becoming a participant in the TC at the first meeting are:
(a) you must be an employee or designee of an OASIS member organization or an individual member of OASIS, and
(b) you must join the Technical Committee, which members may do by using the Roster "join group: link on the TC's web page at [a].
To be considered a voting member at the first meeting:
(a) you must join the Technical Committee at least 7 days prior to the first meeting (on or before 06 November 2018; and
(b) you must attend the first meeting of the TC, at the time and date fixed below (12 November 2018).
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 [b]. 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 [c].
Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards organization; we encourage your participation.
âCALL FOR PARTICIPATIONâ
OASIS Variability Exchange Language (VEL) Technical Committee
The charter for this TC is as follows.
(1)(a) TC Name
OASIS Variability Exchange Language (VEL) Technical Committee
(1)(b) Statement of Purpose
VEL TC members will develop an interoperability standard that will enable the exchange of variability information among variant management tools and systems development tools. VEL will eliminate the cost of building customized interfaces by defining a standard way for information to be exchanged between tools.Â
Variability is a widely used model for describing common and unique features of systems at all stages of the lifecycle. It describes the ability of artifacts to be used in different contexts by changing or customizing some characteristics of them, and those changeable characteristics are localized somewhere within the artifacts.
Tools for variant management frequently interact with artifacts such as model based specifications, program code, or requirements documents. This is often a two-way communication: variant management tools import variability information from an artifact, and in return export variant configurations. For example, they need to gather information about the variation points contained in the artifact, identify which variants are already defined, and then modify existing or define new variants.
At present, however, there is no standard that would define how variation points are expressed in different artifacts.Â That means that a supplier who builds a variants management tool has to implement an individual interface to each tool that is used in a development process to create the corresponding artifacts.
There is currently no standardized API to support two-way communication, so variant management tools need to implement a separate interface -- and possibly a new data format as well -- for each new artifact. Worse, each variant management tool needs to do this separately. With m variant management tools and ân âartifacts, this may require the implementation of up to âm x nâ different interfaces.
Variant management tools and development tools inherently operate at odds with one another. Variant management tools represent and analyze the variability of a system abstractly and define system configurations by selecting demanded features. System development tools, on the other hand, are designed to capture specific kinds of information, such as requirements, architecture, component design, or tests. In order to support variable systems, development tools must either offer the capability to express variability directly or provide an add-on piece of software that does.
The goal of the OASIS Variability Exchange Language (VEL) TC is to enable the exchange of variability information among tools for variant management tools and systems development tools. VEL will eliminate the cost of building customized interfaces by defining a standard way for information to be exchanged among corresponding tools. Using VEL, a variant management tool will be able to read the variability from a development tool and pass configurations of selected system features to a development tool.Â
By defining a common variability data interface that can be implemented by both the development tools and the variant management tools, VEL will enable a continuous development process for variable systems and more flexible use of tools.
The TC will accept as input the following initial contributions:
1. VEL Specification Document
2. Enterprise Architect Model
3. XML Schema
4. Schulze, Michael, and Robert Hellebrand. "Variability Exchange Language-A Generic Exchange Format for Variability Data." Software Engineering (Workshops). 2015.
The TC will refine these initial contributions to produce OASIS standard specifications, including necessary supporting documentation. Further contributions, including other interfaces and domain models from TC members, will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit insofar as they conform to this charter.
The scope of the TCâs work is limited to technical refinements to the features defined in the input contributions. Modest extensions to the Variability Exchange Language that substantively increase interoperability will also be considered. However, the TCâs main focus is to refine the functionality presented in the input documents. Other contributions will be collected and can be considered in subsequent versions of the standard.
Out of Scope
The following is a non-exhaustive list provided only for the sake of clarity. If some function, mechanism or feature is not mentioned here, and it is not mentioned as in-scope in the Scope of Work section, then it will be deemed to be out of scope.
The following items are specifically out of scope of the work of the TC:
* Defining variability/variation points within arbitrary development artifacts
* Mapping of VEL constructs to any kind of development artifact
* Interaction schemes or workflows between tools
* Adding unnecessary complication to the protocol by extending beyond the scope described above
Contributions to this TC which are out of scope for this charter may be accumulated and taken into consideration for potential development of a charter for another technical committee that may be created to address future extensions or modifications to VEL.
The TC will produce within 12 to 16 months
* an XML schema setting the vocabulary, constraints and semantics of the VEL format, and
* a written specification, describing the XML schemaâs elements and attributes in plain English.
(1)(e) IPR Mode
This TC will operate under the âNon-Assertionâ IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy.
The VEL standard will be designed for use in automotive, avionics, automation, transportation, electronics, healthcare, and any industry where variants exist.Â
The anticipated audience for participating in VEL standardization and supporting its adoption includes:
1. Providers of products and/or services designed to host or support systems and software development.
2. Implementers of solutions that require interoperability between variant management tools and system development tools.
3. Authors of other specifications that require a variability data exchange format.
4. Consultants, educators, and interested parties.
The OASIS Variability Exchange Language (VEL) Technical Committee will conduct its business in English.
(2) Non-normative information regarding the startup of the TC
(2) (a) Similar or Applicable Work
Similar or related work in the area of languages and exchange formats in general is manifold, but usually is more centered around the exchange of application data like geographical information (GPS Exchange Format â GPX) or multimedia data (Broadcast Metadata Exchange Format â BMF) to name just two. However, if the context is more on data needed for developing systems, the picture looks different. Focusing further on the exchange of development data supporting variability information, the number of existing related work is rather low.
Some standards like AUTOSAR, EAST-ADL, or IP-XACT define exchange formats and to different extents it is possible to cope with variability. For example, IP-XACT has a notion of a variant, enabling the specification of those elements that are belonging to a variant. What is not supported is to describe which elements are variable at all. In contrast to IP-XACT, EAST-ADL has the notion of variation points and thus provides the functionality to indicate model elements as variable but on the other side EAST-ADL has no notion of a variant. AUTOSAR supports both concepts and thus is the most complete solution with respect to variability. The downside even of the AUTOSAR solution is that the provided possibilities are not generic enough to be used in other contexts as for which they were designed for.
A promising language for the generic description of variability is the Common Variability Languages (CVL), since CVL provides all needed concepts to cope with variability in a generic, and where possible, artifact independent way. The disadvantage of the language specification is the lack of a serialized data representation, which may be usable for the exchange between tools. In contrast to CVL, which describes how to realize variability description inside a tool, VEL specifies a communication interface and a data exchange format. The interpretation and use of the exchanged data remain the responsibility of the tool providers.
(2) (b) Date, Time, and Location of First Meeting
The first meeting will be held through teleconference on 4-5pm (CET) Nov 12th, 2018 and pure-systems GmbH will sponsor this call.
(2)(c) On-Going Meeting Plans & Sponsors
The TC intends to meet by teleconference every two weeks. Sponsorship for these meetings will be rotated through the Organizational Members represented on the TC.
(2)(d) Proposers of the TC
(2)(e) Statements of Support
I, Danilo Beuche, Danilo.Beuche@pure-systems.com
, as OASIS primary representative of pure-systems GmbH organization, confirm our support for the VEL Technical Committee charter and endorse our proposers listed above as named co-proposers.
I, Jon Geater, Jon.Geater@thalesesecurity.com
, as OASIS primary representative for Thales, confirm our support for this proposed Charter and endorse our participants listed below as named co-proposers: Eric Gauthier, Jean-Christophe Orhant, Gilles Malfreyt.
I, Marquart Franz firstname.lastname@example.org
as Siemens primary representative to OASIS, confirm our support for the VEL Technical Committee proposed charter and the participation of our organization's co-proposer [Joana Corte-Real, Bill Chown] as named above.
I, Martin TÃrngren, email@example.com
, as OASIS primary representative for KTH Royal Institute of Technology, confirm our support for the proposed Charter and TC for standardizing the âVariability Exchange Languageâ. I endorse our participants as named co-proposers: Damir Nesic, KTH Royal Institute of Technology.
I, Martin Sarabura, firstname.lastname@example.org
, as OASIS primary representative of PTC Inc., confirm our support for the VEL Technical Committee charter and endorse our proposer listed above as a named co-proposer.
I, Gauthier Fanmuy, email@example.com
, as OASIS primary representative for Dassault SystÃmes, confirm our support for TC for standardizing the Variability Exchange Language. I endorse our participant as named co-proposer: Himanshu CHAWLA.
(2)(f) TC Convener
The TC Convener for the first meeting will be Michael Schulze from pure-systems GmbH.
(2)(g) Affiliation to Member Section
(2)(h) Initial contributions:
Those are given in under Section (1)(c) Scope.
Chief Technical Community Steward
OASIS: Advancing open standards for the information societyhttp://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393Â