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: unsubsribe


Hello Patrick

 

Please unsubscribe me.

 

Troy

 

From: oasis-charter-discuss@lists.oasis-open.org [mailto:oasis-charter-discuss@lists.oasis-open.org] On Behalf Of Patrick Durusau
Sent: September-21-18 5:03 PM
To: oasis-charter-discuss@lists.oasis-open.org
Subject: Re: [oasis-charter-discuss] Call for Comment: proposed Charter for Variability Exchange Language (VEL) Technical Committee

 

Greetings!

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!

Patrick

 

 

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

 

None

 

(2)(h) Initial contributions:

 

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

 

--


/chet 
----------------

 

Looking forward to Borderless Cyber 2018, 3-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
http://www.oasis-open.org

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



-- 
Patrick Durusau
patrick@durusau.net
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 


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