OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-charter-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [oasis-charter-discuss] Call for Comment: proposed Charter for Variability Exchange Language (VEL) Technical Committee


Very interesting looking work in an important area! Welcome to OASIS!

After looking at VariabilityExchangeLanguage-1.pdf and paper11.pdf, which reads in part:


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 that are contained in the artifact, need to know which variants are already defined, and then modify existing or define new variants ("this variation point stays, that one goes away") or even define new variation points ("artifact elements a,b and c are alternatives").


I have a question.

If I have a schema valid instance of a variability-exchange-models instance, and as the paper suggests, it is exchanged or or more times and modified as a result of that interchange, how do I track the revisions and the sources of revisions, made to the original instance?

I'm assuming that tracking responsibility for changes is as important as identification of the changes, from one version of the instance to another.Â

The solution could be something as simple as mandatory recording of the last application to make any changes, so it starts with one named application and any subsequent changes are signaled by sibling application elements. Assuming you have all the versions, simple xml diffing would be sufficient. You may want something more sophisticated but since I raise the issue, I wanted to suggest a minimal solution.

Again, welcome to OASIS! Looking forward to seeing your TC work products issue for TAB review. (Apologies, I should have mentioned it sooner, I'm one of the members of the Technical Advisory Board and collectively we comment on proposals, work products and such.)

Hope everyone has started or is about to start a great weekend!


On 09/18/2018 11:01 AM, Chet Ensign wrote:
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.

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 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 homepage 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 (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

Michael Schulze pure-systems GmbH michael.schulze@pure-systems.com

Uwe Ryssel pure-systems GmbH uwe.ryssel@pure-systems.com

Gilles Malfreyt Thales gilles.malfreyt@thalesgroup.com

Eric Gauthier Thales eric.gauthier@thalesgroup.com

Jean-Christophe Orhant Thales jean-christophe.orhant@thalesgroup.com

Joana Corte-Real Siemens joana.corte-real@siemens.com

Damir Nesic KTH Royal Institute of Technology damirn@kth.se

(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


(2)(h) Initial contributions:

Those are given in under Section (1)(c) Scope.



Looking forward toÂBorderless Cyber 20183-5 Oct, Washington, D.C.
Organized by The World Bank, OASIS, and Georgetown University

Chet Ensign
Chief Technical Community Steward
OASIS: Advancing open standards for the information society

Primary: +1 973-996-2298
Mobile: +1 201-341-1393Â

Patrick Durusau
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau 

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]