Changes between Version 6 and Version 7 of CMDI 1.2/Resource proxies/Single reference
- Timestamp:
- 03/25/14 07:43:43 (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
CMDI 1.2/Resource proxies/Single reference
v6 v7 7 7 == The issue == 8 8 9 With OAI-PMH its possible to retrieve multiple records with one request . 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.9 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. 10 10 11 11 == The proposed solution == 12 === Discussion === 13 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"). 12 14 13 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 xs:keyrefs. A solution in CMDI 1.2 would be to make the type of @ref IDREF again as it was once.An investigation of the around half million harvested CMD records shows that instances of [http://catalog.clarin.eu/ds/ComponentRegistry/?item=clarin.eu:cr1:p_1345561703620# collection] profile are currently the only users of this feature, e.g., the [http://hdl.handle.net/1839/00-F78BED6F-D8DA-4355-BF41-88F6D4A169F8 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.15 An investigation of the around half million harvested CMD records shows that instances of [http://catalog.clarin.eu/ds/ComponentRegistry/?item=clarin.eu:cr1:p_1345561703620# collection] profile are currently the only users of this feature, e.g., the [http://hdl.handle.net/1839/00-F78BED6F-D8DA-4355-BF41-88F6D4A169F8 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. 14 16 17 No other use-cases for keeping the @ref as IDREFS has been put forward. 18 19 === Proposal === 20 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. 21 22 === Implementation example from [[CmdiMultipleRecords]] === 23 Below is shown how the uniqueness problem may be solved by using xs:key and xs:keyref in comp2schema.xsl: 24 {{{ 25 <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"> 26 ... 27 <xs:element name="CMD"> 28 ... 29 <!-- Resource key and reference constraints --> 30 31 <xs:key name="ResourceProxy"> 32 <xs:selector 33 xpath="cmd:Resources/cmd:ResourceProxyList/cmd:ResourceProxy"/> 34 <xs:field xpath="@id"/> 35 </xs:key> 36 37 <xs:keyref name="ResourceRef" 38 refer="cmd:ResourceProxy"> 39 <xs:selector xpath=".//*"/> 40 <xs:field xpath="@ref"/> 41 </xs:keyref> 42 43 </xs:element> 44 </xs:schema> 45 }}} 46 47 48 ---- 49 = Old stuff: = 15 50 === Pros === 16 51
