Changes between Version 6 and Version 7 of ComponentVersioning
- Timestamp:
- 06/11/12 14:40:03 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ComponentVersioning
v6 v7 33 33 For each component the following will be specified and communicated to the client: 34 34 35 * A flag indicating whether the component is deprecated ('false' by default) 36 * A (possibly empty) set of ''direct'' successors 35 * A '''status''' indication, one value out of 36 * '''private''' (to be accessed (read/edit) only by owner(s)) 37 * '''development''' (editable by owner(s), readable by anyone, queryable but not in public listing) 38 * '''public''' (listed publicly, read-only to everyone) 39 * '''deprecated''' (no longer in public listing, queryable and read-only to everyone) 40 * A (possibly empty) set of ''direct'' '''successors''' 37 41 38 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. [http://catalog.clarin.eu/ds/ComponentRegistry/rest/registry/profiles /registry/profiles]). However, they will still be available by their ID (like [http://catalog.clarin.eu/ds/ComponentRegistry/rest/registry/profiles/clarin.eu:cr1:p_1297242111880 /registry/profiles/clarin.eu:cr1:p_1297242111880]). 42 The !ComponentRegistry web service (and as a result this will also apply to the Flex-based component browser) will not display deprecated components in the currently existing public or private listings (e.g. [http://catalog.clarin.eu/ds/ComponentRegistry/rest/registry/profiles /registry/profiles]). However, they will still be available by their ID (like [http://catalog.clarin.eu/ds/ComponentRegistry/rest/registry/profiles/clarin.eu:cr1:p_1297242111880 /registry/profiles/clarin.eu:cr1:p_1297242111880]). 43 44 There will be calls to query for development and deprecated components. 39 45 40 46 There will be a call to list all direct (and possibly also recursive) successors of a specific component (see XML example below). … … 46 52 === Storage / internal representation === 47 53 48 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.54 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 'status' 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. 49 55 50 56 === Client information === 51 57 52 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.58 Because most clients will consume the XSD transformation of components, the status and 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: '''Status''' and '''!SuccessorsList'''. The contents of these will come from the database. 53 59 54 60 Example: … … 61 67 <Name>LrtInventoryResource</Name> 62 68 <Description>Resources as stored before in the CLARIN LRT inventory</Description> 63 < Deprecated>true</Deprecated>69 <Status>deprecated</Status> 64 70 <SuccessorsList>http://catalog.clarin.eu/ds/ComponentRegistry/rest/registry/profiles/clarin.eu:cr1:p_1289827960126/successors</SuccessorsList> 65 71 </Header> … … 79 85 <xs:annotation> 80 86 <xs:appinfo> 81 <cmd: Deprecated>true</cmd:Deprecated>87 <cmd:Status>deprecated</cmd:Status> 82 88 <cmd:SuccessorsList>http://catalog.clarin.eu/ds/ComponentRegistry/rest/registry/profiles/clarin.eu:cr1:p_1289827960126/successors</cmd:SuccessorsList> 83 89 </xs:appinfo> … … 85 91 }}} 86 92 93 == Notes == 94 95 * Only owners (and admins) can change the status of a component (as is the case with publishing now) 96 * Deprecation and succession will require a reason (for deprecation) or comment (for new version) 97 87 98 == Discussion == 88 99 89 * Should we limit deprecation and versioning to published components? (what does it mean for an unpublished component to get deprecated?)90 100 * Should 'bi-directional' versioning information be provided or just successors? (should a successor component refer to its precursor?) 91 101 * What to do with many-to-many relations in versioning? (merging and branching of components)
