To OASIS Members:
A draft TC charter has been submitted to establish the
OASIS Variability Exchange Language (VEL) Technical
Committee. In accordance with the OASIS TC Process Policy
section 1.2Â (
https://www.oasis-open.org/policies-guidelines/tc-process#formation)
the proposed charter is hereby submitted for comment. The
comment period shall remain open until 23:59 UTC on 02
October 2018.
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 (VEL TC) in the subject line of your
email message.
--- TC Charter ---
Section 1: TC Charter
(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.
(1)(c) Scope
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 TCs 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 with 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.
(1)(d) Deliverables
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 schemas
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.
(1)(f) Audience
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.
(1)(g) Language
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
marquart.franz@siemens.com 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] as named above.
I, Martin Trngren,
martint@kth.se, 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.
(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
None
(2)(h) Initial contributions:
Those are given in under Section (1)(c) Scope.
--
/chetÂ
----------------
Organized
by The World Bank, OASIS, and
Georgetown University
Chet Ensign
Chief Technical
Community Steward
OASIS: Advancing open standards for the
information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393Â