Comments to the Public Review of the OSLC Core 3.0 Specifications

Dear OSLC TC members,

we recently started to evaluate the possibilities of OSLC 2.0 and the state of current tool-implementations. In particular we are interested in the interoperability of requirement management tools. We are glad to see that there is an active development for the Core 3.0 specifications. We just learned about the Public Review some days ago and we missed the deadline. Still, we would like to use the chance to comment on some topics that came to our mind, when working with OSLC 2.0 and reading the new 3.0 specifications.

To start with we would recommend update the Core 3.0 webpage on open-services.net (http://open-services.net/wiki/core/Specification-3.0/). Our first impression was that the development of core 3.0 is dead, since the last update was November 2013. We found the Public Review only by chance.

Before I come with our comments, I think I would be helpful to explain our background. For the last month/year we helped a customer to introduce ReqIF for exchanging requirements. As preparation steps we tested the ReqIF-Implementations of IBM DOORS, IBM DOORS Next Generation and Polarion extensively. We also performed test-exchanges with partner companies of our customer. Thereby we also learned a bit about the problems and shortcomings of the ReqIF implementation in various other RM-Tools like PTC Integrity and Siemens Teamcenter. We therefore had the chance to get a bit of experience of what can go wrong when introducing new Standard and the obstacles on the way to a productive use. OSLC seems to be an interesting alternative or supplement for ReqIF in some use cases, offering features ReqIF was not designed for. It therefore arouse our interest.

Some of the following comments may concern a future “Requirements Managements 3.0” Domain Specification, but we think that most concerns are general enough to be considered for the Core 3.0 Specification.

### 1) Representation of resources: ###

Changing the support of RDF/XML from “must” to “should” will break the backward compatibility.

### 2) Definition of data structures: ###

# 2a) Constraint language for data structures

One of our most important concerns was already addressed in 3.0: To move the “Instance Shape” from the appendix to the specification itself. Also, we strongly recommend making the use of the “instanceShape” property mandatory for all resources! Without a rigid and machine-readable definition of the data structure of a resource, a communication and exchange of data via OSLC is simply impossible for most scenarios we can think of.

The Core 3.0 specification states, that other constraint languages such as SHACL could be used. We understand that this increases the flexibility. And any domain specification could anyway be more restrictive. But we are worried, that this flexibility will lead to a lot of isolated tool-specific implementations, all being “OSLC-Conform”, but none of them can understand each other. Also adding support for other domains into one’s own existing implementation could become a pain, if a completely new technology-stack has to be implemented each time. So it could be beneficial for the acceptance of OSLC 3.0 if you stick to the “Instance Shape”-concept.

We think that the success of a Standard does strongly dependent on the premise, that a tool that implements the standard must not worry about how any other tool is doing the implementation! This point is also expressed in some of the following comments on more specific topics.

# 2b) “Instance Shape”: Identification/Mapping of the data structure

From ReqIF we know how important it is, that each tool can map the data structure of the format to its one internal data structure. To achieve that, not only the resources themselves have to be identifiable, but also the elements describing the type/characteristics of the resource and its properties (“resource-type” and “property-type”).

If a resource is described by an “Instant Shape”-resource, the URI of the “Instant Shape” can be used for mapping. (e.g. for DOORS Next: to an “artefact type”).

In an “Instance Shape” resource, properties are defined in ”Property”-resources. These resources are defined inline within a “Instance Shape”-represenation. Therefore they may or may not have an URI. Here we recommend changing the “oslc:property” representation from “Inline” to “Resource”. Then the URI can be used for mapping (e.g. in DOORS Next: to an attribute definition). As far as we understand, currently only the property name can be used to identify a oslc:Property resource, but in many tools (e.g. DOORS Next, Polarion) the name of an attribute does not need to be unique.

# 2c) “Instance Shape”: valueType

Within an “oslc:Property”-resource the oslc:valueType is “zero-or-one”. We recommend to change this to “exactly-one”. Without knowing the basic datatype of the property is hard for a tool to interpret the contained data.

# 2d) “Instance Shape”: creating new resource shapes

As far as we understand, new resources can only be created on the basis of “Resource Shapes” that are known to the server. It would be helpful to have the possibility to tell an OSLC-Server about a new “Resource Shape”, so that resources of this type can be created subsequently.

# 2e) “Instance Shape”: additional properties for “core#Property”

We recommend adding the two optional properties “minValue” and “maxValue”, to set a limit for the range of allowed values for Integer, decimal, float and double. These parameters are e.g. used in the ReqIF datatype definitions and some RM-Tools (IBM DOORS and IBM DOORS Next Generation).

# 2f) “Instance Shape”: oslc:allowedValues

From the text, it wasn’t clear to us how an “oslc:allowedValues”-Resource is actually defined.

# 2g) “Instance Shape”: enumerations

In our experience enumerations are very important. The specification only recommends a way to specify enumerations in part 7. In the document part 6 (“Resource Shape”) enumerations are not mentioned at all. For the application of OSLC to requirement management it is absolutely necessary to have the possibility do define enumerations.

We recommend to add a way to define enumerations to part 6 (“Resource Shape”) of the specification. We also recommend that there is a defined way to specify the order of the literals.

A simple way could be:

a) Define a new Resource “EnumLiteral”, which has the properties “number” (integer, to define the order), name “string” and “value” (string).
b) Define a new (zero-or-many) property in “core#Property” with “EnumLiteral” as range. It could be named “enumLiterals”. These are all the allowed literals.
c) Define a new “Literal Value Type” for the property “oslc:valueType” called “enumeration”. The allowed value is an URI to an “EnumLiteral”-resource.

This concept is similar to way it is done in ReqIF, where it has proved to be useful in practice.

### 3) General aspects of resources

In the RM-world most tools are representing requirements within a hierarchical-structure. This structure carries important semantic information. We could imagine that this is also the case in other domains. We would therefore recommend to add optional “parent” and ”child”-properties (valueType “Resource”) to every resource. Maybe also something like “sibling-nr”, to define the order of siblings.

### 4) Formatted Text ###

From our experience with ReqIF we know that the transfer of formatted text can cause a lot of trouble. In case of requirements, formatted text is very important, if not the most important aspect. A user has to rely on the assumption, that an exchange partner can display any formatted text correctly in his tool. If e.g. a bullet list would be formatted in a way that another tool does not support, important information may be lost. In our opinion this is a huge factor for the acceptance of a standard (at least for RM). The problem is that all tools we have worked with have to translate the formatting in their own formatting-style. They are not simply rendering the content in a browser, since they must provide editing functionality.

We recommend adding a dedicated “XHTML-Literal” to the list of “Literal Value Types”. It could be based on “rdf:XMLLiteral”, but the content that is allowed is restricted. The must only contain a XHTML <span> element, whereby only a reduced set of XHTML-Tags is allowed. The list of allowed tags could be taken from the ReqIF-Standard.

Looking at the trouble we had in the past with this topic, we can hardly imagine that text, formatted in full XHTML, will not result in a lot of incompatibilities. Also writing an implementation will become a pain for the developer.

### 5) Authentication ###

For some authentication methods a user interaction is necessary (as e.g. 3-legged-OAuth). It would be very helpful, if an implementation would always offer at least one way to avoid this (e.g. with 2-legged-OAuth or HTTP basic authentication). This is needed to facilitate automatic data transfer. Maybe it should be mandatory to implement at least one authentication method, which does not require a user to become active?

Best regards,

Dr. Tim Meyer

REQUISIS GmbH

Walter-Benjamin-Platz 8

D-10629 Berlin

oslc-core-comment message