This page is a subpage of CMDI 1.2

Allowing only a single reference from a component (or element) to a resource proxy

The issue

With OAI-PMH its possible to retrieve multiple records with one request (bulk retrieval). When one validates the returned document its possible that IDs clash, as they are unique within the original XML document but there was no requirement that they should have been globally unique.

The proposed solution

Discussion

It's possible in XSD to limit the scope of IDs and IDREFs using xs:key and xs:keyref. This solution has been described in the CmdiMultipleRecords page. A showstopper for this solution is currently that @ref can refer to multiple ResourceProxies, i.e., the type of @ref is IDREFS, while there is no mechanism to ensure uniqueness of the items in IDREFS across documents (no "xs:keyrefs").

An investigation of the around half million harvested CMD records shows that instances of ​collection profile are currently the only users of this feature, e.g., the ​IPROSLA Abel CMD collection record. Here the root collection component refers to all the ResourceProxies. Its debatable if that is needed, as this should be the default interpretation if there is no @ref.

No other use-cases for keeping the @ref as IDREFS has been put forward.

Proposal

In CMDI 1.2 we propose to make the type of @ref IDREF (as it was once), and use xs:key and xs:keyref to constrain the @ref value (see implementation example below). This will allow bulk retrieval through OAI, while not posing a serious reduction of expressivity - considering current practice.

Implementation example from CmdiMultipleRecords

Below is shown how the uniqueness problem may be solved by using xs:key and xs:keyref in comp2schema.xsl:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:dcr="http://www.isocat.org/ns/dcr" xmlns:cmd="http://www.clarin.eu/cmd/" targetNamespace="http://www.clarin.eu/cmd/" elementFormDefault="qualified">            
...
    <xs:element name="CMD">
...                
        <!-- Resource key and reference constraints -->
                
        <xs:key name="ResourceProxy">
            <xs:selector
                xpath="cmd:Resources/cmd:ResourceProxyList/cmd:ResourceProxy"/>
            <xs:field xpath="@id"/>
        </xs:key>
                
        <xs:keyref name="ResourceRef"
            refer="cmd:ResourceProxy">
            <xs:selector xpath=".//*"/>
            <xs:field xpath="@ref"/>
        </xs:keyref>
                
    </xs:element>
</xs:schema>

---

Old stuff:

Pros

CMD records can be concatenated for bulk retrieval.

Cons

There are CMD records that currently use multiple ResourceProxy references in one @ref.

Centre impact

When a centre uses references to multiple resource proxies in one @ref these would have to be modeled differently.

Implementation examples

See the CmdiMultipleRecords page.

Discussion

Discuss this solution proposal in this section

Tickets

Tickets in the CMDI 1.2 milestone with the keyword keyword:

Ticket	Summary	Owner	Component	Priority	Status
No tickets found

Discussion

Discuss the topic in general below this point

Florian(BAS): In the meeting 2014-01-23 I claimed that there is an use case for multiple refs to elements of the ResourceProxyList? from one component, namely actor components refering to multiple resources. Although this is theoretically possible, we don't do that: it's the other way round: an element of the ResourceProxyList? refers to multiple speaker-components, but we use the 'actor-ref' attribute instead of 'ref' for that.