Schema element "b:life_cycle"
A group of fields which maintain the status of the unit; units
may require maintenance, even when you do not like it. First read
the explanation of the
life-cycle.
Definitions
<element name="life_cycle" type="b:LifeCycle" />
<complexType name="LifeCycle">
<sequence>
<element ref="b:revision" [0..1] />
<element name="created" type="dateTime" [0..1] />
<element name="updated" type="dateTime" [0..1] />
<element name="deprecate" type="b:Expression" [0..1] />
<element name="expire" type="b:Expression" [0..1] />
<element name="revisit" type="b:Expression" [0..1] />
</sequence>
</complexType>
Description
The revision MUST be upgraded each time the unit
sees any change: it is used to invalidate cached values.
Revisions are ASCII sortable strings. Only the newest revision of a
unit should be used by your program: older revisions have value.
The revision defaults to updated, which
is an ordered date format. On its turn, updated defaults
to created.
For each of the time-stamps, you will not see who has set or
changed them inside the unit itself: that could become quite expensive.
The collection of units MAY have a separate archive which contains or
produces change-logs. See msc:Type/ChangeLog.
element created
This tells you something about the moment data has been collected for
the first time: the moment the Unit appeared in the system.
element deprecate
This tells the Collection when the author of the Unit wants it to
get deprecated. The expression must produce a timestamp: be an absolute
dateTime or a duration after the moment of publication.
When a unit has a deprecated time which is in the past, then attempts
should be made to warn the user of data in the unit. Details can be
found in the unit's change-log. Warnings MUST be throttled to an
acceptable level, say a maximum of once per hour.
element expire
This tells the Collection when the Unit wants to get expired.
The expression must produce a timestamp: be an absolute datetime or
a duration after the moment of publication.
When a unit has expired, it SHALL NOT be used anymore. It MUST
be thrown away within a reasonable period, but at least within
one hour after expiration.
Also, Units which are packaged may expire. In this case, the whole
package is expired. When there are still units inside that package which
are not expired, you MUST either expire them as well or repackage them.
Probably the latter. This may be expensive.
element revision
See b:revision. Defaults to the value of
updated, which contains a date which is string-sortable.
element revisit
The maximum in which you have to check whether you still have the
latest revision of a unit. The expression must return a duration.
When you use a cached unit (of any type)
you must check whether the collection which contains that unit has
to be upgraded, using the ms:Op.upgrade operation.
All reported changes need to be processed before you can continue.
It is RECOMMENDED to have a background process performing this task,
such that "normal" processed are not delayed in the synchronization.
Upgrades of units are shown as atomic operations.
It is RECOMMENDED to revisit the units at least every half of the
revisit duration. You SHALL have revisited the unit before the timespan
has ended, or throw the cached revision of the unit away.
You SHALL not keep the revision unit in any form after the revisit
timespan has passed without revision attempt, to comply to law.
element updated
The "last-modified" time-stamp reflects any change on the data or
meta-data of the unit. This includes changes detected in the
references which the unit has to other data.
The revision is already increased on each of the updates,
which will automatically upgrade all copies of the unit. The revision
may look like a date, but does not need to be.
Updated defaults to created.
mark@overmeer.net
Web-pages generated on 2023-12-19
| 
