The purpose of this page is to come to a design for an extension of the ComponentRegistry that will enable versioning and deprecation of components and profiles.

Component versioning

Definitions

• Component refers to both components and profiles as specified by the general component schema that exist in the ComponentRegistry;
• Versioning refers to the precursor/successor relation that may exists between two components. It does not imply a structural or functional extension or inheritance, i.e. the structure of the precursor component does not put any constraints on the structure of the successor relation; no assumptions about the structure of the' one can be made on basis of the structure of the other. Versioning does not imply deprecation (see below) of the precursor.
• Deprecation refers to a state in which a component is no longer 'advertised' by the registry (it will not appear in the list of published components) and will be explicitly marked as such to the client. However it will still be accessible by its URI so that instances based on deprecated components will remain valid. Apart from this, the properties of published components apply. Deprecation can optionally be combined with versioning.

Design

For each component the following will be specified and communicated to the client:

• A flag indicating whether the component is deprecated ('false' by default)
• A (possibly empty) set of direct successors

The ComponentRegistry web service (and as a result this will also apply to the Flex-based component browser) will not display deprecated components in any listing (e.g. ​/registry/profiles). However, they will still be available by their ID (like ​/registry/profiles/clarin.eu:cr1:p_1297242111880).

There will be a call to list all direct (and possibly also recursive) successors of a specific component (see XML example below).

Both the XML representation of a component and the XSD that results from the comp2schema transformation should contain deprecation and versioning information in some form (see below for a proposal).

Implementation

Storage / internal representation

The ComponentRegistry web service has a PostgreSQL back-end in which it stores both the component specifications in their verbatim XML formatting and 'component metadata' (referred to as 'descriptions' to avoid ambiguity) containing fields such as 'creator' and 'group'. The 'deprecated' property can be added to this. To accommodate the successor relations, an additional table has to be added simply linking precursors and successors, and optionally storing a comment on each relation.

Client information

Because most clients will consume the XSD transformation of components, the deprecation/versioning information will have to be represented in these profile schemata. It can be provided within an xs:appinfo element. This information can be taken from two proposed new optional header elements in the component specification: Deprecated and SuccessorsList. The contents of these will come from the database.

Example:

<CMD_ComponentSpec isProfile="true">
   <Header>
      <ID>clarin.eu:cr1:p_1289827960126</ID>
      <Name>LrtInventoryResource</Name>
      <Description>Resources as stored before in the CLARIN LRT inventory</Description>
      <Deprecated>true</Deprecated>
      <SuccessorsList>http://catalog.clarin.eu/ds/ComponentRegistry/rest/registry/profiles/clarin.eu:cr1:p_1289827960126/successors</SuccessorsList>
   </Header>

in the XSD this would be transformed to:

<xs:schema xmlns:cmd="http://www.clarin.eu/cmd/"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:dcr="http://www.isocat.org/ns/dcr"
      xmlns:ann="http://www.clarin.eu"
      targetNamespace="http://www.clarin.eu/cmd/"
      elementFormDefault="qualified">
   <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
   <xs:annotation>
      <xs:appinfo>
         <cmd:Deprecated>true</cmd:Deprecated>
         <cmd:SuccessorsList>http://catalog.clarin.eu/ds/ComponentRegistry/rest/registry/profiles/clarin.eu:cr1:p_1289827960126/successors</cmd:SuccessorsList>
      </xs:appinfo>
   </xs:annotation>

Discussion

• Should we limit deprecation and versioning to published components? (what does it mean for an unpublished component to get deprecated?)
• Should 'bi-directional' versioning information be provided or just successors? (should a successor component refer to its precursor?)
• What to do with many-to-many relations in versioning? (merging and branching of components)