Contracts are behavioral descriptions of Web services. We devise a theory of contracts that formalizes the compatibility of a client to a service, and the safe replacement of a service with another service. The use of contracts statically ensures the successful completion of every possible interaction between compatible clients and services. The technical device that underlies the theory is the filter, which is an explicit coercion preventing some possible behaviors of services and, in doing so, make services compatible with different usage scenarios. We show that filters can be seen as proofs of a sound and complete subcontracting deduction system which simultaneously refines and extends Hennessy’s classical axiomatization of the must testing preorder. The relation is decidable and the decision algorithm is obtained via a cut-elimination process that proves the coherence of subcontracting as a logical system. Despite the richness of the technical development, the resulting approach is based on simple ideas and basic intuitions. Remarkably, its application is mostly independent of the language used to program the services or the clients. We outline the practical aspects of our theory by studying two different concrete syntaxes for contracts and applying each of them to Web services languages. We also explore implementation issues of filters and discuss the perspectives of future research

Abstract. We present a streamlined theory of session types based on a simple yet general and expressive formalism whose main features are semantically characterized and where each design choice is semantically justified. We formally define the semantics of session types and use it to define the subsessioning relation. We give a coinductive characterization of subsessioning and describe algorithms to decide all the key relations defined in the article. We then apply the theory to statically ensure progress for a simple π-based process calculus, give examples, and discuss related work. 1.

Abstract. We illustrate the concepts of sessions and session types as they have been developed in the setting of the π-calculus. Motivated by the goal of obtaining a formalisation closer to existing standards and aiming at their enhancement and strengthening, several extensions of the original core system have been proposed, which we survey together with the embodying of sessions into functional and object-oriented languages, as well as some implementations.

XML transformations are very sensitive to types: XML types describe the tags and attributes of XML elements as well as the number, kind, and order of their sub-elements. Therefore, operations, even simple ones, that modify these features may affect the types of documents. Operations on XML documents are performed by iterators that, to be useful, need to be typed by a kind of polymorphism that goes beyond what currently exists. For this reason these iterators are not programmed but, rather, hard-coded in the language. However, this approach soon reaches its limits, as the hard-coded iterators cannot cover fairly standard usage scenarios. As a solution to this problem we propose a generic language to define iterators for XML data to be grafted on some host programming language. We show that our language mostly offers the required degree of polymorphism, study its formal properties, and show its expressiveness and practical impact by providing several usage examples and encodings.

Abstract. We present a streamlined theory of session types based on a simple yet general and expressive formalism whose main features are semantically characterized and where each design choice is semantically justified. We formally define the semantics of session types and use it to define the subsessioning relation. We give a coinductive characterization of subsessioning and describe algorithms to decide all the key relations defined in the article. We show that all monomorphic dyadic session types proposed in the literature are particular cases of our session types. 1

Structural type systems provide an interesting alternative to the more common nominal typing scheme. Many existing languages employ structural types in some form, including Modula-3, Scala and various extensions proposed for Java. Previous work has addressed many aspects of structural types, such as efficient subtyping algorithms. Unlike nominal type systems, implementing a (recursive) structural type system remains a significant challenge. This is because a large gap exists between the formalisation of a recursive structural type system, and its algorithmic realisation. In this paper, we aim to reduce this gap by providing a generic framework that succinctly captures the important algorithmic issues. The framework is not tied to any particular structural type system, and can be instantiated in a variety of ways. Finally, by way of motivation, we illustrate some common instantiations of our framework. 1

In general, typechecking refers to the problem where, given a program P, an input type σ, and an output type τ, one must decide whether P is type-safe, that is, whether it produces only outputs of type τ when run on inputs of type σ. In the XML context, typechecking problems mainly arise in two forms: •XML-to-XML transformations, where P transforms XML documents conforming to a given type into XML documents conforming to another given type; and •XML publishing, where P transforms relational databases into XML views of these databases and it is necessary to check that all generated views conform to a specified type. A type for XML documents is typically a regular tree language, usually expressed as a schema written in a schema language such as DTD, XML Schema, or a Relax NG (see XML Types). In the XML publishing case, the input type σ is a relational database schema, possibly with integrity constraints. Typechecking problems may or may not be decidable, depending on (1) the class of programs considered, (2) the class of input types (relational schemas, DTDs, XML Schemas, Relax NG schema, or perhaps other subclasses of the regular tree languages), and (3) the class of output types. In cases where it is decidable, typechecking can be done exactly. In cases where it is undecidable, one must revert to approximate or incomplete typecheckers that may return false negatives—i.e., may reject a program even if it is type-safe. Even when exact typechecking