How to work without transactions

Fedora has no concept of transactions. There are situations where this is simply not good enough for the DOMS system. To get around this, we have built a system which gives us the most nessesary benefits of transactions.

Each data object in the DOMS is in one of three States.

draft - The object is still under preparation. The object can be edited freely. It is not available for public dissemination, and is disregarded by the validator.
published - The object is finished, and should be valid in regards to datamodel. The object is available for public dissemination.
intermediate - The object published, but is temporarily offline, as it is being updated. It is not available for public dissemination and will be disregarded by the validator.

The transition between these three states can be seen here

attachment:StateTransition.jpeg

Newly created objects will always be in the draft state. Once a user decide the object is ready for the public, the state should be changed to published. This will cause the validator to run, and if the object is valid, it will be published. Otherwise, the object will remain in draft, and the user will be notified about the errors.

Once the object is published, it can never revert to the draft state. If something needs to be changed, the object can be taken offline for a little while. The exact procedure is like this:

Load the object(s) locally, and perform the changes in your local version(s).
Change the state of the object(s) to intermediate
Write your changes to the object(s).
Change the state back to published. If your changes broke (any of) the object(s), the validator will report errors, and the state will not change (for these objects).

The State representation in an object

We have chosen to store the state as a rdf literal. This means Ressource Index queries about it are possible, which

The schema for the STATE datastream can be seen here

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance#"
            targetNamespace="http://doms.statsbiblioteket.dk/properties/state/0/1/#"
            xmlns="http://doms.statsbiblioteket.dk/properties/state/0/1/#"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified">

    <xsd:element name="state" type="extpropertiesType"/>

    <xsd:complexType name="extpropertiesType">
        <xsd:attribute name="value" type="valuesType"/>
    </xsd:complexType>

    <xsd:simpleType name="valuesType">
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="published"/>
            <xsd:enumeration value="intermediate"/>
            <xsd:enumeration value="draft"/>
        </xsd:restriction>
    </xsd:simpleType>
</xsd:schema>

It is defined in the datastream STATE_SCHEMA in ContentModel_DOMS.

The STATE datastream will therefore look like

<s:state value="published" xmlns:s="http://doms.statsbiblioteket.dk/properties/state/0/1/#"/>

<s:state value="intermediate" xmlns:s="http://doms.statsbiblioteket.dk/properties/state/0/1/#"/>

<s:state value="draft" xmlns:s="http://doms.statsbiblioteket.dk/properties/state/0/1/#"/>