Semantic Version Management based on Formal Certiﬁcation

Jean-Yves Vion-Dury and Nikolaos Lagos

Xerox Research Centre Europe, 6 chemin de Maupertuis, 38330 Meylan, France

Keywords:

Semantic Versioning, Version Management, Software Versioning.

Abstract:

This paper describes a Semantic Version Management method that enables managing consistently digital re-

sources throughout their life cycle. The core notion is that resources are described be means of logical speci-

ﬁcations formally expressed using an extensible logical language. A new version is considered certiﬁed only

if the resource owner is able to formally prove that it satisﬁes its logical speciﬁcation. The method includes

formal proofs for qualifying changes (occurring either on the resource content or on the corresponding spec-

iﬁcations) and accordingly characterizing them via the deﬁnition of appropriate version labels. Based on the

above method, a service-oriented solution is also described that enables managing changes consistently, in a

sound manner, for both resource owners and users.

1 INTRODUCTION

Versioning is particularly challenging in dynamic,

non-centralized architectures, as propagating changes

in a consistent manner requires strict coordination of

tiers. Such a case is for example service-oriented ar-

chitectures, where the separation of the service in-

terface from its implementation, often referred to as

opacity, is an additional complexity (changes in the

interface or the implementation may impact the con-

tract that the service provider has with a consumer

from a functional or quality-of-service (QoS) point)

(Novakouski12).

This work presents a method towards Version

Management that enables consistent management of

digital resources throughout their life cycle for the

beneﬁt of both resource owners/providers (the entities

offering the resource) and resource users (the entities

using the resources), and exempliﬁes it in a service-

oriented setting. As part of the method we deﬁne how

resources can be associated with logical speciﬁcations

written in an extensible logical formalism understood

and agreed by tiers. We also describe how a service

can verify the well-formedness of proofs and prop-

erties when required, so that the version labels stay

consistent

For the sake of space only a small number of evolu-

tions are described in this paper. However, all possible evo-

lutions are deﬁned and available online (Vion-Dury15) for

interested readers.

2 RELATED WORK

Version management includes deﬁning strategies

for: version naming (which should aid in record-

ing the evolution of a resource); and for identify-

ing/responding to different updates (which should be

related to controlling the consistency of different ver-

sions). In this work we deal with both of the above

issues and integrate them into a single framework.

Version naming is most typically designed to re-

ﬂect consumer

compatible and non-compatible (or

breaking and non-breaking) changes. The former

constitute major releases and the latter minor ones.

The corresponding naming usually follows the ”Ma-

jor#.Minor#” scheme where the sequential major re-

lease version number precedes the minor one (Jer-

ijrvi08). Alternatively naming schemes may incor-

porate a time-stamp instead of the above identiﬁer.

However, the above naming schemes provide very

limited semantic information about the relationships

between versions (Conradi98).

Recent work, especially in the area of web ser-

vices, recognises the importance of having seman-

tic information relevant to versioning and try to in-

ject such information. For instance, (Juric09) ex-

tends WSDL and UDDI with corresponding meta-

data. In (Wetherly13) and (Cacenco06) a three-label

version scheme is proposed, where each label is in-

cremented in response to changes in the versioned re-

source (in their case each label corresponds to one of

data components, message components and features).

Vion-Dury J. and Lagos N..

Semantic Version Management based on Formal Certiﬁcation.

DOI: 10.5220/0005511300190030

In Proceedings of the 10th International Conference on Software Paradigm Trends (ICSOFT-PT-2015), pages 19-30

ISBN: 978-989-758-115-1

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

(Vaivaran09) goes one step further by not only assign-

ing semantics to version labels but also using them

to determine the compatibility between entities (e.g.

UML processes) and source code modules. However,

the naming scheme is deﬁned by the provider and it

is the job of the consumers to use this consistently.

Our method allows separate identiﬁers for the service

owner/provider and each of the users(s)/consumer(s).

Based on this idea we propose the use of a dedicated

versioning service implementing our method, which

would ensure the consistency of the mapping between

the different identiﬁers.

Similar work can be found, in terms of formal-

ising the evolution of artifacts in dynamic environ-

ments, as proposed by (Papazoglou12), where a the-

oretical type-safe framework is proposed to ensure

correct versioning transitions in service-oriented en-

vironments. Although their method sketches the rela-

tion between the notion of compatibility and speciﬁ-

cations, they do not provide any formal grounding on

how the modelling of consistent change is reﬂected by

the naming scheme of different variants. In addition,

they do not refer at all to the notion of a dedicated

versioning service functioning as broker, a direct ver-

sioning approach being implied to the best of our un-

derstanding. In direct approaches the consumer and

provider are directly connected and each one has to

manage changes to their requirements and offer re-

spectively. In our case, we propose an intermediary-

based approach, where the consumer does not have

to communicate with the provider directly but only

through a third service (i.e. a broker). The broker

is responsible for managing the changes happening to

any of the connected services (a preferred approach in

the context of service-oriented environments is (Leit-

ner08)).

Another close work is done by (Brada03). The

author formalises the notion of component versioning

to support consistent substitutability of components

and falls under the umbrella of software conﬁgura-

tion management for component-based systems. Al-

though very interesting, the work is mainly focused

on a speciﬁc architecture (widely used for software

components) called CORBA (CORBA).

3 THE VERSIONING MODEL

3.1 Invariants, Speciﬁcations, Theories

We represent the logical characterisation of a resource

via two logical formulae: the ﬁrst one is the invari-

ant, i.e. the logical properties that the resource must

always satisfy during its life cycle; the second one,

speciﬁcation, is a logical formula that may change

over time, but that the resource must satisfy in or-

der to be certiﬁed. The certiﬁcation of a resource

is therefore a formally established proof that the new

version is consistent with the resource logical spec-

iﬁcation. Consequently, a version increment can be

generated (the choice of the increment type is left to

the owner, but must satisfy speciﬁc logical properties,

as explained later in the paper).

Associating an invariant with a versioned resource

captures the fundamental fact that if a resource owner

intends to derive versions, then something commons

to all versions should be preserved. Otherwise, ver-

sions are not needed, one just need to derive a new

resource with a different name and different logical

characteristics, and start a novel life cycle.

What is the role of the speciﬁcation ? We assume

that versioning systems should have an abstract de-

scription that explains what is the resource and how

it can be used. For instance, this can be a document

describing an API (Software Enginering and Service

Oriented Architectures), it can be an SQL schema for

a data set, a formal context free grammar for a source

code written in a speciﬁc programming language, an

XSD schema for an XML document, and so on. A

speciﬁcation can also be used to describe tests that a

resource should pass in order to be considered valid.

We also distinguish between:

• external speciﬁcation, describing the behaviour

that is expected by users of the resource, e.g. an

API exposing methods to a service’s clients.

• internal speciﬁcation, describing the behaviour

that is expected by the owner of the resource, e.g.

support for changes in the code and documenta-

tion.

Such a speciﬁcation is formally expressed in this

work using an underlying core logic L (see section

4.2.1 and a speciﬁc, owner designed, theory T , which

extends the core logic with axioms and theorems suit-

able to handle the owner’s applicative domain.

The key idea is that the versioning method, pre-

sented in this paper, is based on formal proofs to cer-

tify a versioning step. Such a proof will take the form

of a proof term, i.e a particular data structure that re-

ﬂects exactly how the proof was constructed from the

axioms and the theorem. Although it can be hard to

build such a proof, it is easy to verify that it is well-

formed and that it is indeed a proof of the claimed

property.

3.2 Structure of Version Labels

In our model, a resource r represents a digital con-

tent (its digital extension as a bitstream) and is related

ICSOFT-PT2015-10thInternationalConferenceonSoftwareParadigmTrends

to a unique identiﬁer and a version label deﬁned as

[M.m.µ : ν]/s, where M,m,µ,ν,s are natural numbers

greater or equal to 0. The number M stands for ma-

jor revision, m for minor, µ for micro, ν for variant

and s for stamp. Minor versions preserve the back-

ward compatibility (while possibly offering new func-

tionalities); micro versions have no visible impacts

from the external speciﬁcation point of view (im-

provements, bug ﬁxes, simpliﬁcations...); while major

versions may require revising the processes depend-

ing on the changing resource (this scheme is coined as

Semantic Versioning (OSGi)). The advantage of this

scheme is that it is a straightforward way to commu-

nicate to the users of a resource whether its evolutions

are backward compatible or incompatible.

The stamp is incremented at each modiﬁcation op-

eration, independently of versioning mechanisms. As

a consequence, a resource can be updated and never

versioned, meaning that the changes can be tracked

and memorized, but without any assumptions regard-

ing its semantic properties. A resource r is certi-

ﬁed when a versioning operation was able to logically

establish its compliance with its semantic speciﬁca-

tion(s). The version label is designed in order to re-

ﬂect this, as the variant component must be null.

3.3 Version based Ordering

Version labels are built in such a way that they can be

totally ordered for a given resource, i.e. it is always

possible to assess if one version is anterior to another

one. This is important since, thanks to this property,

one can always ﬁnd the antecedent of a given version

based on the label structure. We deﬁne ﬁrst an order

≺ on version labels through:

∀M,M

,m,m

,µ,µ

,ν,ν

,s,s

non negative integers

M < M

⇒ [M.m.µ : ν]/s ≺ [M

.µ

: ν

]/s

m < m

⇒ [M.m.µ : ν]/s ≺ [M.m

.µ

: ν

]/s

µ < µ

⇒ [M.m.µ : ν]/s ≺ [M.m.µ

: ν

]/s

ν < ν

⇒ [M.m.µ : ν]/s ≺ [M.m.µ : ν

]/s

s < s

⇒ [M.m.µ : ν]/s ≺ [M.m.µ : ν]/s

Version labels evolve in such a way that the following

property always holds.

Proposition 1. Monotonicity of stamps

∀M

,µ

,ν

non negative integers

[M.m.µ : ν]/s ≺ [M

.µ

: ν

]/s

⇒ s < s

Intuitively, this property says that for a given re-

source r, the stamp stamp(r) = s tracks all change

history regardless of the evolution of the version la-

bel (which is ruled by the preservation of signiﬁcant

semantic properties, as detailed later). In order to ab-

stractly handle resources, we deﬁne three so called

destructors to access those attributes:

identiﬁer(r) = `

content(r) = c

version(r) = [M.m.µ : ν]/s

Similarly, versioning labels can be de-constructed ac-

cording to the following functions:

major([M.m.µ : ν]/s) = M

minor([M.m.µ : ν]/s) = m

micro([M.m.µ : ν]/s) = µ

update([M.m.µ : ν]/s) = ν

stamp([M.m.µ : ν]/s) = s

Given the above, we can build a partial order over

versioned resources as follows.

Deﬁnition 1. partial ordering of resources

∀r, r

r ≺ r

iff identiﬁer(r) = identiﬁer(r

) ∧ version(r) ≺ version(r

)

3.4 Designation and Selection of

Resources

To be able to select and retrieve resources, we deﬁne

herein the designation mechanism. Resources can be

designated through a term built from the following

syntax:

D ::= ` | `[V

] | `/s | `/? | `/?

::= ? | ? | M | M.V

::= ? | ? | m | m.V

::= ? | ? | µ

? denotes all available components that match some

versioning constraints, whereas ? denotes the highest

available component, and therefore, is always a sin-

gleton (or the empty set if the condition is not satis-

ﬁed). The notation `[?] designates the set containing

all versions of the resource `, `[?] the last qualiﬁed

version, `[3.?] designates the last minor and micro

version derived from the major revision 3 of `. For

some value M,m, µ the designation `[M.m.µ] always

maps to a singleton (provided this derivation belongs

to the history of the resource), as well as `/s, under

the same condition. The notation `/? designates the

set of all variants of ` regardless of any versioning in-

formation, and `/? the most recent element of this set,

if any.

All resources E can be retrieved through a resolu-

tion function that takes as input the designation term,

and returns a set of resources accordingly. The reso-

lution function, noted ! is deﬁned in Table 1.

4 THE CERTIFICATION MODEL

4.1 The Dynamics of Resources and

Speciﬁcations

We consider three different parameters related to a re-

source that can be changed, according to the model

of resources described in previous sections. The re-

source r, its internal speciﬁcation I

, and its external

SemanticVersionManagementbasedonFormalCertification

Table 1: Resolution of references.

reference result comment certiﬁed

!(`) !(`/?) shorthand

!(`/?) {r ∈ E | identiﬁer(r) = `} all variants yes/no

!(`/?) sup≺[!(`/?)] last variant yes/no

!(`/s) {r ∈!(`/?) | stamp(r) = s} a particular variant yes/no

!(`[M]) !(`[M.?]) shorthand

!(`[?]) sup≺[!(`[?])] last version yes

!(`[?]) {r ∈!(`/?) | major(version(r)) > 0} all variants yes

!(`[M.m]) !(`[M.m.?]) shorthand

!(`[M.?]) sup≺[!(`[M.?])] last M version yes

!(`[M.?]) {r ∈!(`/?) | major(version(r)) = M} all M versions yes

!(`[M.m.µ]) {r ∈!(`[M.m.?]) | micro(version(r)) = µ} this version yes

!(`[M.m.?]) sup≺[!(`[M.m.?])] last M.m version yes

!(`[M.m.?]) {r ∈!(`[M.?]) | minor(version(r)) = m} all M.m versions yes

r `[1.1.3 : 0]/13

`[1.1.3 : 1]/14

`[1.1.3 : 2]/15

`[1.1.3 : 3]/16

`[1.2.0 : 0]/16

version

Figure 1: Example updates for a resource r with identiﬁer `

and speciﬁcation I

speciﬁcation E

,c. The triple hr,I

r,c

i may evolve

in many different ways, but to be certiﬁed, the fun-

damental property described in section 4.3.1 must al-

ways be veriﬁed. Still, uncertiﬁed resources have a

versioning label and therefore can be designated and

retrieved. By construction, a version label having a

non zero variant is uncertiﬁed. For instance, Fig-

ure 1 illustrates two evolution steps of a resource r,

and then an evolution step of its internal speciﬁca-

tion I

(e.g. to take in account added features). These

three update operations are applied on a certiﬁed re-

source (with version label `[1.1.3 : 0]/13). The ﬁrst

two steps track modiﬁcations of the resource content,

whereas the third one tracks the modiﬁcation of the

internal speciﬁcation. The last step corresponds to a

minor qualiﬁcation, to establish that the fundamental

invariant is satisﬁed: the resource satisﬁes the modi-

ﬁed speciﬁcation and this one is a logical extension of

the original speciﬁcation (and is thus backward com-

patible). From this last property, we can deduce that

the modiﬁed speciﬁcation is also a logical extension

of the invariant, since the original speciﬁcation was.

4.2 The Underlying Logic and Its

Implementations

The intent of this section is not to deﬁne a particular

logic suitable to handle the logical mechanisms de-

scribed in this paper, but, to make clear which qual-

ities are expected from such a logic. The expres-

siveness of the logic theoretically depends on the re-

quirements of the application; however, the higher

order logic is commonly used today, implemented

with powerful proof assistants, embedding interac-

tive/automated tactic based theorem provers (Coc-

quand86; Nipkow02), and is generic enough to cover

practical cases.

4.2.1 Logic L

This logic, called L , should be equipped with a partic-

ular relation that checks well-formedness of terms, in

order to be sure that a logical speciﬁcation is indeed

a term that can be managed by axioms and theorems.

We note this relation wf(P), or equivalently, using a

generic typing relation, as type(P, prop). This logic L

must also be equipped with a proof system able to ex-

plicitly handle proof terms. We note L ` proof(p,P)

the logical relation establishing that p is is a proof

of P in L . Consequently, proving a property P is a

process that will construct a proof term p. In gen-

eral, it is much more difﬁcult to build the proof term

than to check for its correctness, the latter being usu-

ally implemented through simple and efﬁcient algo-

rithms (see for instance how proof terms are han-

dled through lambda term in the COC higher order

type theory (Cocquand86), how proofs become ﬁrst

order entities in (Kirchner10), and also in OpenThe-

ory (Hurd11) and Dedukti (Boespﬂug12; Saillard13)

which proposes a universal and pivotal proof handling

mechanism; more generally, see how proof terms are

built and computed in any logic based on the Curry-

ICSOFT-PT2015-10thInternationalConferenceonSoftwareParadigmTrends

Howard correspondence (De Bruijn95)).

We expect also that extensions suited to domain

speciﬁc applications will be expressed as additional

theories T

,··· that will be designed to work

on top of L. In those cases, the L , T

,··· `

proof(p,P) will be the natural extension of the nota-

tion presented above, to express a proof in the afore-

mentioned set of theories.

To illustrate, let us consider the higher order in-

tuitionistic logic L (whose associated proof system is

based on natural deduction (Laboreo05), where elimi-

nation and introduction rules are associated with each

construct). If we consider a formula like

∀A.∀B.((A ∧ B) ⇒ B)

A proof using sequents and natural deduction could

be for instance

A ∧ B ∈ A ∧ B,

∈

B ∈ B, A ∧ B,

∈

B ∈ A,B,A ∧ B,

∈

A,B, A ∧ B,

0 ` B

A ∧ B,

0 ` B

∧

0 ` (A ∧ B) ⇒ B

⇒

0 ` ∀B.(A ∧ B) ⇒ B

∀

0 ` ∀A.∀B.(A ∧ B) ⇒ B

∀

This proof can be mapped into a structurally equiva-

lent proof term using all applied rule names

∀

⇒

∧

(∈

)))))))

which can be checked for correctness using a dedi-

cated predicate proof(p,P) :

∈

∴ A ∧ B ∈ A ∧ B,

∈

∴ B ∈ B, A ∧ B,

∈

(∈

) ∴ B ∈ A,B, A ∧ B,

∈

(∈

)) ∴ A,B,A ∧ B,

0 ` B

∧

(∈

)) ∴ A ∧ B,

0 ` B

∧

⇒

∧

(∈

))) ∴

0 ` (A ∧ B) ⇒ B

⇒

∀

⇒

∧

(∈

)))),I

(∈

))))) ∴

0 ` ∀B.(A ∧ B) ⇒ B

∀

⇒

∧

(∈

))))) ∴

0 ` ∀A.∀B.(A ∧ B) ⇒ B

∀

4.2.2 Fundamental Logical Relations and

Properties

When a resource r satisﬁes a logical formula F, this is

noted as r |= F. The @ relation expresses strict logical

implication, i.e

@ F

iff F

⇒ F

∧ ¬(F

⇒ F

)

whereas v expresses the logical implication (there-

fore, is reﬂexive):

v F

iff F

⇒ F

The u

relation expresses ”partial disjunction”, i.e,

that a logical intersection F exists between two for-

mulas:

iff F @ F

∧ F @ F

∧ ¬(F

v F

)

Deﬁned this way, this relation produces two subcases:

one where F

@ F

is strictly more speciﬁc than

) and one where ¬(F

@ F

) (F

and F

are strictly

conjunctive). Both situations make sense when in-

terpreting major version evolution (which potentially

can raise incompatibility issues). The ﬁrst one ex-

presses cases where a speciﬁcation is restricted (pro-

ducing some regression in the expectation), the other

one expresses situations where a speciﬁcation evolves

by extending some points, but regressing on others.

The ≈ relation just expresses logical equivalence

(but is typically used when F

and F

are syntactically

distinct):

≈ F

) iff F

⇔ F

It is easy to show that the @,v,≈ relations are

transitive, and since the logic is expected to be sound,

we also assume the following property holds:

v F

∧ r |= F

) ⇒ r |= F

We denote the change of the resource r into r

a particular δ relation, such that δ(r) = r

4.3 Certiﬁcation of Resources and

Speciﬁcations

When a client asks that a resource r is certiﬁed (cre-

ation of a new major, minor or micro version), he/she

must provide one or several proofs, depending on

the past operations and the current context (some

cases are detailed in section 4.3.2). The proofs are

checked for correctness, i.e, the system veriﬁes that

they indeed establish the expected properties P

L,T

,··· ` proof(p,P

). Moreover, depending on

the kind of change, some ”structural” properties may

be veriﬁed: well-formedness of changed speciﬁca-

tions and that the resource satisﬁes the speciﬁcations.

Checking a proof is easy, while building the proof

term (formally proving a property) can be of un-

bounded difﬁculty, depending on the application do-

main (and consequently on the power of theories op-

erated by the resource owners). However, many use-

ful scenarios can be captured by simple theories, and

proofs can be established either by a proof assistant or

even by specialized programs, such as type checkers,

or specialized algorithms. Note that run-time execu-

tion performance of such programs would not be as

crucial as during development cycles, since they are

involved only during the certiﬁcation phase. Prop-

erties such as schema membership (XML validation,

database relational schema) can be processed auto-

matically by dedicated algorithms, as long as those

schemes are translated into L inside an appropriate

theory. Similarly, API signatures for a software li-

brary, making use of decidable type systems, can be

similarly processed through an equivalent approach.

SemanticVersionManagementbasedonFormalCertification

Section 4.3.2 details some change cases with re-

spect to the versioning certiﬁcation. The changes in-

volve three entities: the resource r, its internal speci-

ﬁcation I

, and its external speciﬁcation E

r,c

for a par-

ticular client c.

4.3.1 Version Consistency

The certiﬁcation process aims at controlling the evo-

lution of the tuple hr,I

r,c

i for all resources r, for

all clients c of r and associated speciﬁcations I

and

r,c

, and the invariant I

. This is achieved in a way

that the resource satisﬁes all speciﬁcations, and the

external speciﬁcation visible by the client is a spe-

cialization of the internal speciﬁcation (controlled by

the owner). Both external and internal speciﬁcations

must always specialize the initial invariant I

. This

fundamental scheme is illustrated in the following di-

agram.

r,c

r I

|= |=

4.3.2 Version Co-evolution

We examine changes potentially affecting any of the

three dynamic parameters (therefore, excluding the

invariant I), focusing on the consequences both from

the clients’ and owner’s perspectives, in terms of how

their respective version labels will evolve. The ele-

ments with red color correspond to the logical rela-

tions that must be established, whereas the green ones

express what can be deduced both from the previously

established relations and from the proved statements

(and therefore, do not need require formal treatment).

As many combinations exist, we explicit here only

two cases: the ﬁrst one deals with unchanged re-

sources but evolving speciﬁcations (no change regard-

ing the resource itself, but changes to the correspond-

ing speciﬁcations), while in the second case the re-

source changes as well. See (Vion-Dury15) for the

exhaustive list of cases.

Update describing Changing Speciﬁcations and

unchanged Resources: The ﬁgure 2 shows a cer-

tiﬁcation scheme where the client considers a change

as having a major effect.

Update with Changing Resources: We distinguish

three cases, from the point of view of a client c, work-

ing with an external speciﬁcation E

r,c

over a resource

client Certiﬁcation owner required deducible

version scheme version proofs properties

r,c

′

r,c

⊓

⊑

wf(E

′

r,c

)

r,c

⊓

′

r,c

′

r,c

⊑ I

r |= E

r,c

r |= E

′

r,c

′

r,c

′

⊓

⊑

≈

⊑

wf(E

′

r,c

)

r,c

⊓

′

r,c

′

r,c

⊑ I

′

wf(I

′

)

≈ I

′

r |= E

r,c

r |= I

′

r |= E

′

r,c

′

r,c

′

⊓

⊑

⊏

⊑

wf(E

′

r,c

)

r,c

⊓

′

r,c

′

r,c

⊑ I

′

wf(I

′

)

⊏ I

′

r |= I

′

r |= E

r,c

r |= E

′

r,c

′

r,c

′

⊓

⊑

⊓

⊑

wf(E

′

r,c

)

r,c

⊓

′

r,c

wf(I

′

)

⊓

′

r |= I

′

r,c

⊑ I

′

r |= E

r,c

r |= E

′

r,c

Figure 2: Update with changing speciﬁcations and un-

changed resource: client sees a major evolution (M, m and

µ stands for major, minor, micro).

r. Figure 3 covers major changes with an evolving

external speciﬁcation.

5 VERSION BROKER SERVICE

This section presents a service-oriented application

setting for the method described in the previous sec-

tions. We consider that a specialised broker can offer

services related to versioning (and generally resource

lifecycle management) by implementing our method

as described herein. We call that service the Version

Broker Service (VBS).

We distinguish between two roles for the service’s

clients: the resource owner and the resource user. The

resource owner publishes one or several logical de-

scriptions, at various levels of precision, which char-

acterize the resource and will serve as a basis for the

formal agreement about its intended use. Users may

subscribe to a ”contract” (e.g. Quality of Service

agreement) and get access to the resource through a

dedicated version management scheme. Each time

the owner certiﬁes a new version, the VBS will make

sure that this change is propagated to the ”contracts”,

i.e that each version label associated with the con-

tracted interface is derived in a semantically consis-

tent way. In the remaining part of the section we de-

scribe in more detail what the service offers but also

requires from the owners and users of the resources.

ICSOFT-PT2015-10thInternationalConferenceonSoftwareParadigmTrends

client Certiﬁcation owner required deducible

version scheme version proofs properties

c,r

′

c,r

⊓

⊑

wf(E

′

c,r

)

c,r

⊓

′

c,r

′

|= I

′

c,r

⊑ I

′

r |= E

r,c

′

|= E

′

r,c

c,r

′

c,r

′

⊓

⊑

≈

⊑

wf(E

′

c,r

)

c,r

⊓

′

c,r

′

|= I

′

c,r

⊑ I

′

wf(I

′

)

≈ I

′

r |= E

r,c

′

|= E

′

r,c

c,r

′

c,r

′

⊓

⊑

⊏

⊑

wf(E

′

c,r

)

c,r

⊓

′

c,r

′

c,r

⊑ I

′

wf(I

′

)

⊏ I

′

|= I

′

r |= E

r,c

′

|= E

′

r,c

c,r

′

c,r

′

⊓

⊑

⊓

⊑

wf(E

′

c,r

)

c,r

⊓

′

c,r

′

c,r

⊑ I

′

wf(I

′

)

⊓

′

c,r

⊑ I

′

|= I

′

r |= E

r,c

′

|= E

′

r,c

Figure 3: Major changes with an evolving external speciﬁ-

cation (M, m and µ stands for major, minor, micro; δ denotes

a modiﬁcation of the resource).

5.1 The Resource Owner

The resource owner creates the resource and deﬁnes

how it evolves. This includes deciding when and

how to publish the resource and also what type of ac-

cess and use should be allowed for different users.

The owner also deﬁnes the domain speciﬁc theo-

ries needed (or use/extend those that might be pro-

posed by the VBS), and design the properties needed

to characterize the provided resource. The resource

extension (its bitstream) might be directly uploaded

into the VBS inner storage space, or just localized

through a pointer that allows the VBS to access the

content when needed. The actions that the VBS al-

lows/expects from the resource owner are:

Theory creation. Upload a source ﬁle compatible with

the underlying logic (see section 4.2) supported by

the VBS, and an associated name that must be unique

for this owner. This means that the VBS has a dedi-

cated parser and computational means to verify/type

the provided deﬁnitions (check for well-formedness).

Once loaded and veriﬁed by the VBS the deﬁnitions

can be used in other operations.

Resource creation. Allows to specify a name uniquely

associated with the target resource. This name will be

used to designate the revisions thanks to the version

labels, as in cobra.socket.api, which could be subse-

quently referenced as in e.g. cobra.socket.api[1.2.0].

Internal speciﬁcation creation. VBS expects the re-

source name to which the speciﬁcation will be at-

tached, and a logical formula, which will be checked

for well-formedness. The VBS returns a unique iden-

tiﬁer, so that the speciﬁcation can be designated with-

out ambiguity for future operations. External speciﬁ-

cation creation. idem (see above).

Resource update. Upload a novel extension for the re-

source, or equivalently, apply a patch; a new internal

version label is computed accordingly (see update in

Table 2).

Speciﬁcation update. Upload a novel extension for

the resource (or equivalently, apply a patch); a new in-

ternal version label is computed accordingly (see up-

date in Table 2).

Qualiﬁcation. This corresponds to the ﬁrst stage in-

volving a logical characterization. Once certiﬁed, the

resource can be derived and made visible to exter-

nal users. As parameters, the VBS expects the re-

source label ` = identiﬁer(r), a reference to the in-

variant property I

and to the internal speciﬁcation

, and the following proofs (see 4.3.1): (i) the in-

variant is implied by the internal speciﬁcation in the

deﬁned context L,T

` I

v S

and (ii) the resource

satisﬁes the internal speciﬁcation in the deﬁned con-

text L , T

` ` |= S

The VBS then veriﬁes the proofs

and if correct, qualiﬁes the resource, generating the

ﬁrst certiﬁed version label (see Table 2).

Derivation. Compute a new version for a resource,

whose name is given as a parameter, as well as the

type of version: micro, minor, or major. Depending

on the version type, different proofs will be required

by the VBS, so as to minimize the proving cost (see

ﬁgure 4).

Publication. Requires the resource’s name as pa-

rameter and synchronizes the last certiﬁed version

to generate the external version labels for all users.

Proofs will be asked by the VBS according to the co-

evolution schemes (see section 4.3.2).

In the following, we use x

to denote x + 1. Table

2 deﬁnes the transformations of the version label ac-

cording to the operation done on a resource r, where

version(r) = [M.m.µ : ν]/s:

5.2 The Resource User

The resource user accesses the bitstream extension

(the resource content) corresponding to particular

versions, thanks to the designation mechanism

described in section 3.4. The corresponding external

speciﬁcation may also be accessed.

SemanticVersionManagementbasedonFormalCertification

Table 2: Operations supported by the Version Broker Service and corresponding impact on version labels.

operation on resource version label (before) version label (after) certiﬁed

creation n.a. [0.0.0 : 1]/0 no

qualiﬁcation [0.0.0 : ν]/s [1.0.0 : 0]/s yes

major derivation [M.m.µ : ν]/s [M

.0.0 : 0]/s yes

minor derivation [M.m.µ : ν]/s [M.m

.0 : 0]/s yes

micro derivation [M.m.µ : ν]/s [M.m.µ

: 0]/s yes

update [M.m.µ : ν]/s [M.m.µ : ν

]/s

Certiﬁcation version required deducible

scheme kind proofs properties

ℓ S

′

≈

L, T

⊢ S ≈ S

′

L, T

⊢ ℓ |= S

′

ℓ S

ℓ

′

micro L, T

⊢ ℓ

′

|= S none

ℓ S

ℓ

′

≈

L, T

⊢ ℓ

′

|= S

′

L, T

⊢ S ≈ S

′

none

ℓ S

′

⊏

minor L, T

⊢ S ⊏ S

′

L, T

⊢ ℓ |= S

′

ℓ S

ℓ

′

⊏

L, T

⊢ ℓ

′

|= S

′

L, T

⊢ S ⊏ S

′

none

ℓ S

′

⊓

ℓ

major

L, T

⊢ ℓ |= S

′

L, T

⊢ S ⊓

ℓ

′

none

ℓ S

ℓ

′

⊓

ℓ

L, T

⊢ ℓ

′

|= S

′

L, T

⊢ S ⊓

ℓ

′

none

Figure 4: Certiﬁed evolution of a resource ` according to a

speciﬁcation S (δ denotes a modiﬁcation of the resource).

The operations that the VBS supports for users of the

resource include:

Resource download. VBS expects a full version

label (e.g. d p.api[2.1.3]), and returns a set of

resource contents, associated with its exact version

label. Such a label will resolve into this particular

content if a subsequent access is required. As an

example, a ﬁrst request with db.api[1.2.?] may return

{(c

,db.api[1.2.1]),(c

,db.api[1.2.2])} (where c

denotes the respective bitstream contents) whereas a

db.api[1.2] request will be interpreted by the VBS

as db.api[1.2.?] and would return the last content

available for this major and minor version in the

given context, i.e. the singleton {hc

,db.api[1.2.2])} .

Speciﬁcation download. Using the same communica-

tion scheme, the resource user may access each ex-

ternal speciﬁcation associated with each version re-

solved by the VBS.

6 ILLUSTRATIVE EXAMPLE

In this section we present an example that illustrates

the concepts introduced in the previous sections. We

assume that a provider manages a software library of-

fering persistent storage operations. We call the li-

brary STO and assume that it is made available as a

compiled module. The owner of STO chooses to ex-

pose two different views of this library: a basic one

including creating/opening a persistent store, storing,

deleting, and retrieving data, and a more complex one

that can additionally handle transactions. We assume

that the owner of STO uses an object-oriented dedi-

cated theory to describe the resource, focusing on the

naming and typing of classes and methods.

6.1 Fundamental Invariant

The fundamental invariant of STO is deﬁned in terms

of a class, three methods to deal with data, and three

basic functions to create,open and delete a database.

ST O

≡ class(STOHandler)

∧ language(Python2)

∧ method(STOHandler,store)

∧ method(STOHandler,retrieve)

∧ method(STOHandler,close)

∧ function(create)

∧ function(open)

∧ function(delete)

Note that according to the vision of the resource

ICSOFT-PT2015-10thInternationalConferenceonSoftwareParadigmTrends

owner, signatures of methods/functions are not con-

sidered as fundamental, and therefore, could change

along the lifetime of the resource, however, the pro-

gramming language and version must stay stable.

6.2 The External Speciﬁcation

It describes a minimal view on the functionality of-

fered by the API, namely, the signatures of methods

and functions, including potential exceptions as fol-

lows.

ST O

≡ I

ST O

∧ signature(STOHandler.store,[string,string],void)

∧ signature(STOHandler.retrieve,[string], [string])

∧ signature(STOHandler.close,[ ],void)

∧ signature(create,[string], STOHandler)

∧ signature(delete,[string], void)

∧ signature(open,[string],STOHandler)

∧ throw(create,Exception)

∧ throw(delete,Exception)

∧ throw(open,Exception)

6.3 The Internal Speciﬁcation

This one is typically more complex, as expected to

help the designer maintaining his source code in a co-

herent way while hiding (potentially irrelevant) com-

plexity to users. To illustrate this, we decided to con-

sider three additional methods: check (verify the pres-

ence of a data in the store), replace (change a value

using a known key) and put (store one or many val-

ues using the same key). Those methods may be

used internally to build higher level operations such

as the store method which perform storage with re-

placement, as in standard dictionary data structures

based on a hashing algorithm.

ST O

≡ I

ST O

∧ signature(STOHandler.store,[string,string],void)

∧ signature(STOHandler.retrieve,[string], [string])

∧ signature(STOHandler.close,[ ],void)

∧ signature(create,[string], STOHandler)

∧ signature(delete,[string], void)

∧ signature(open,[string],STOHandler)

∧ method(STOHandler,check)

∧ method(STOHandler,replace)

∧ method(STOHandler,put)

∧ signature(STOHandler.check,[string],integer)

∧ signature(STOHandler.replace,[string,string],void)

∧ signature(STOHandler.put,[string,string],void)

∧ class(PathException)

∧ subtype(PathException,Exception)

∧ throw(create,PathException)

∧ throw(delete,Exception)

∧ throw(open,PathException)

Note also that exception management is more

detailed thanks to a class specialization.

6.4 Veriﬁcation of Speciﬁcations

The well-formedness of the logical speciﬁcation is es-

tablished by proofs using both a generic (for the ba-

sic logic operators) and a dedicated theory. In Figure

5 we just give an idea of what the dedicated theory

could be for the illustrative example presented above

(x : y is the inﬁx notation of the predicate type(x,y),

and label, integer,··· are built-in predicates to as-

sess lexical properties of items).

The formal proofs required by the VBS for the

three speciﬁcations will be ` I

ST O

, ` E

ST O

and ` I

ST O

which can be reduced into ` I

ST O

, ` P

and ` P

since

ST O

≡ I

ST O

∧ P

and E

ST O

≡ I

ST O

∧ P

being the

additional properties illustrated by sections 6.2, 6.3).

6.5 First Certiﬁcation

After submitting the internal and external speciﬁca-

tions, the owner wants to produce a ﬁrst certiﬁca-

tion of STO (that is, asks the VBS to generate a cer-

tiﬁed version label ST O[1.0.0 : 0]/0). To that end,

the owner must provide a proof that STO satisﬁes the

speciﬁcation (ST O |= I

ST O

). The computational char-

acterisation of the proof will depend on the power

of the underlying theory, on the properties of the

programming language, and on the difﬁculty of the

task (and also on the performance level of the algo-

rithm/human operator).

In the weakest case, the proof is not pro-

vided by the owner ( in that case the owner as-

sumes responsibility for the consistent use of the re-

source). Yet, proofs of well-formedness (` P), as

well as implication and partial disjunction of prop-

erties are required to control the quality of spec-

iﬁcations and the consistency of the claimed evo-

lution of versions. The absence of strong compli-

ance proofs can be compensated by offering test-

ing infrastructure at the VBS level, and including

runtime tests in the speciﬁcations, e.g. through

dedicated predicates like test(context, code,value) or

raises(context, code,exception), where code, value

and exception are particular expressions of some suit-

able abstract language.

In the strictest case, the programming language

is associated with a formal speciﬁcation system (e.g

based on predicate transformers) able to conduct

semi-automatic proofs of correctness and to export

proof terms in the VBS compliant form.

For intermediate cases, the programming lan-

guage can be associated with static analysis tools

SemanticVersionManagementbasedonFormalCertification

∀P. P: prop ⇒ ` P

∀x,t. t : type ⇒ (x :t): prop

void: type

any: type

type: type

prop: type

integer: type

string: type

∀t. t : type ⇒ list(t): type

∀c. class(c) ⇒ c: type

class(Exception)

∀x. integer(x) ⇒ x :integer

∀x. string(x) ⇒ x :string

∀t. t : type ⇒ [ ]: list(t)

∀e,L,t. t : type ⇒ e :t ⇒ L : list(t) ⇒ [e|L]: list(t)

∀t

. subtype(t

) ⇒ subtype(list(t

),list(t

))

∀t. t : type ⇒ subtype(t,any) ≺

any

∀x,t

. subtype(t

) ⇒ x :t

⇒ x :t

∀c

,m. subtype(c

) ⇒ method(c

,m) ⇒ method(c

,m)

∀t

. subtype(t

) ⇒ subtype(t

)

∀t. subtype(t,t)

∀x. label(x) ⇒ class(x): prop

∀x,y. x :type ⇒ y :type ⇒ subtype(x, y) : prop

∀x. label(x) ⇒ function(x): prop

∀c,m. class(c) ⇒ label(m) ⇒ method(c, m): prop

∀c,m, i, o. method(c,m) ⇒ i : list(type) ⇒ o: type

⇒ signature(c.m,i,o): prop

∀ f , i,o. function( f ) ⇒ i : list(type) ⇒ o: type ⇒ signature( f , i,o): prop

∀c,m, e. method(c,m) ⇒ e : Exception ⇒ throw(c.m,e):prop

∀ f , e. function( f ) ⇒ e : Exception ⇒ throw(f , e) : prop

∀ f , c

. subtype(c

) ⇒ throw( f ,c

) ⇒ throw( f , c

) ≺

throw

∀ f , c

. (i

⇒ i

) ∧ subtype(o

) ⇒ signature( f ,i

)

⇒ signature( f ,i

) ≺

sig

∀t

. subtype(t

) ∧ subtype(T

) ⇒ subtype([t

],[t

])

subtype([ ],[ ])

Figure 5: Example dedicated theory.

(such as type or property checkers using partial eval-

uation or model checking).

To perform the ﬁrst certiﬁcation, the VBS

will require STO |= I

ST O

, I

ST O

v E

ST O

(easy),

ST O

v I

ST O

(easy, but longer), and E

ST O

(a bit more difﬁcult). The only difﬁ-

culty in the last one, is about proving proper-

ties like e.g. throw(create,PathException) ⇒

throw(create,Exception), which requires using ap-

propriate subtyping oriented axioms as follows (proof

scheme in abbreviated form).

∈

subclass(PathException,Exception) ∈ γ

∈

γ ` subclass(PathException,Exception)

γ ` throw(create,PathException) ⇒ throw(create,Exception)

≺

throw

6.6 A Change and Its Co-evolution

To illustrate the notion of co-evolution, we propose

to examine a change that occurs in both the resource

(modiﬁcation of source code and, accordingly, of the

library resource STO) and in the internal speciﬁcation.

Now, the store,retrieve, put and replace methods of

the STOHandler class could accept any kind of value,

and not only strings. This would constitute a major

evolution from the internal side (the new speciﬁcation

is more speciﬁc, that is, δ(I

ST O

) v I

ST O

, whereas the

ST O

need not to be upgraded. As an example, the

proof for the store method would be as follows.

···

subtype([string,string],[string,any])

subtype(void,void)

γ `

signature(STOHandler.store,[string,string],void) ⇒

signature(STOHandler.store,[string,any],void)

ICSOFT-PT2015-10thInternationalConferenceonSoftwareParadigmTrends

7 CONCLUSION

In this paper we presented a method for versioning

that enables managing consistently digital resources

throughout their life cycle. The method assigns ex-

plicit semantics to version labels and describes re-

sources in terms of properties that can be checked for

validity based upon formal logical theories. Only if

these properties are valid the resource is marked as

certiﬁed. We also sketched how this method could be

implemented in a service-oriented setting. We have

shown that following our versioning approach entails

beneﬁts to both resource users and owners. The re-

source users have a strong guarantee with respect to

the versioning of certiﬁed resources. More speciﬁ-

cally, that the versioning scheme always reﬂects in

a consistent way the evolution of the resources they

contracted for. On the other hand, the resource own-

ers receive valuable support for coherently managing

changes between versions while minimizing the re-

quested proofs at each step.

We plan of extending the above work by introduc-

ing, within the same setting, the formal underpinnings

for version branching and merging, and to start exper-

imenting with the main concepts presented in this pa-

per. The challenge of scaling such a system to a real

environment should be understood more concretely,

as well as the level of precision we can expect and

manage regarding the various logical speciﬁcations

involved in a system based on our model.

ACKNOWLEDGEMENTS

We would like to thanks Jean-Pierre Chanod for his

continuous support, and all our partners for the cre-

ative exchanges we had together. This research is con-

ducted under the PERICLES project (PERICLES13),

a four-year Integrated Project funded by the European

Union under its Seventh Framework Programme.

REFERENCES

M. Novakouski, G. Lewis, W. Anderson and J.

Davenport. ”Best Practices for Artifact Ver-

sioning in Service-Oriented Systems,” Soft-

ware Engineering Institute, Carnegie Mellon

University, Pittsburgh, Pennsylvania, Tech-

nical Note CMU/SEI-2011-TN-009, 2012. re-

sources.sei.cmu.edu/asset ﬁles/TechnicalNote/2012

004 001 15356.pdf

K. Jerijærvi and J.-J. Dubray, Contract Versioning, Com-

patibility and Composability,” InfoQ Magazine, Dec.

2008; www.infoq.com/articlescontract-versioning-

comp2

R. Conradi and B. Westfechtel. ”Version mod-

els for software conﬁguration management”.

ACM Comput. Surv. 30, 2 (June 1998), 232-

282. DOI=10.1145/280277.280280 doi.acm.org/

10.1145/280277.280280

M. B. Juric, A. Sasa, B. Brumen and I. Rozman,

”WSDL and UDDI extensions for version

support in web services”. Journal of Sys-

tems and Software, Volume 82, Issue 8, Au-

gust 2009, pp 1326-1343. ISSN 0164-1212,

dx.doi.org/10.1016/j.jss.2009.03.001. www.science

direct.com/science/article/pii/S0164121209000478

Curtis Wetherly, Bryan R. Goring, Michael Shenﬁeld,

Michael Cacenco. System and method for imple-

menting data-compatibility-based version scheme, US

Patent 8,555,272. 2013.

Cacenco, M. and Goring, B. and Shenﬁeld, M. and

Wetherly, C. Implementing data-compatibility-

based version scheme, WO Patent App.

PCT/CA2005/001,345, 2006.

Vairavan, V. and Bellur, U. Method and system for version-

ing a software system. US Patent App. 12/324,950,

2009.

M. P. Papazoglou, S. Benbernou, V. Andrikopou-

los ”On the Evolution of Services,” IEEE

Transactions on Software Engineering, vol.

38, no. 3, pp. 609-628, May-June, 2012 -

preprint, infolab.uvt.nl/ mikep/publications/IEEE-

TSE%20%5Bpreprint%5D.pdf

Leitner, P.; Michlmayr, A.; Rosenberg, F.; Dustdar, S.

”End-to-End Versioning Support for Web Services,”

Services Computing, 2008. SCC ’08. IEEE Interna-

tional Conference on , vol.1, no., pp 59-66, July 2008

- Technical report version doi: 10.1109/SCC.2008.21

www.infosys.tuwien.ac.at/staff/leitner/papers/TUV-

1841-2008-1.pdf

P. Brada. ”Speciﬁcation-Based Component Substi-

tutability and Revision Identiﬁcation”. PhD the-

sis, Charles University, Prague, August 2003,

d3s.mff.cuni.cz/publications/download/brada phd.pdf

CORBA 3.3. Accessed June 26, 2014.

www.omg.org/spec/CORBA/3.3/.

Semantic Versioning, Technical Whitepaper, OSGi Al-

liance, Revision 1.0, May 2010 www.osgi.org

T. Cocquand and G. Huet. ”The Calculus of Constructions”.

INRIA Research Report RR-0530, May 1986.

T. Nipkow, L. C. Paulson and M. Wenzel (ed.). ”Is-

abelle/HOL: a proof assistant for higher-order logic”.

Springer, 2002.

F. Kirchner and C. Mu

noz. ”The Proof Monad.” The Jour-

nal of Logic and Algebraic Programming 79.3 (2010):

264-277.

J. Hurd. The OpenTheory Standard Theory Library. In

NASA Formal Methods, 17791. Springer, 2011.

M. Boespﬂug, Q. Carbonneaux and O. Hermant, ”The

lambda-Pi-calculus Modulo as a Universal Proof Lan-

guage”. In PxTP 2012.

R. Saillard. ”Dedukti: a universal proof checker”. In: Foun-

dation of Mathematics for Computer-Aided Formal-

ization Workshop. 2013.

N. G. De Bruijn. ”On the roles of types in mathematics”.

SemanticVersionManagementbasedonFormalCertification

The Curry-Howard isomorphism, 1995, vol. 8, p. 27-

54.

D. Laboreo. Introduction to Natural Deduction. Tu-

torial, May 2005. www.danielclemente.com/ log-

ica/dn.en.pdf.

PERICLES a FP7 European project. 2013-2017.

www.pericles-project.eu.

J.-Y. Vion-Dury and N. Lagos, Technical Annex

www.xrce.xerox.com/content/download/34443/3724

76/ﬁle/SV-ANNEX.pdf.

ICSOFT-PT2015-10thInternationalConferenceonSoftwareParadigmTrends