Changes between Version 40 and Version 41 of ComposedMetadataRecords

Timestamp:

Apr 27, 2010, 2:54:35 AM (14 years ago)

Author:

simonp

Comment:

--

ComposedMetadataRecords

@@ -39 +39 @@
 
  * XLink resolver and cache - the geocat.ch sandbox has developed an XLink resolver and cache mechanism. The implementation in the BlueNetMEST sandbox uses the same cache mechanism (based on Apache JCS) but parts of the resolver have been rewritten to handle (amongst other things) relative links to fragments in the same record and to avoid caching of such fragments. (See http://geonetwork.svn.sourceforge.net/viewvc/geonetwork/sandbox/BlueNetMEST/jeeves/src/jeeves/xlink). More details:
-  * Metadata Records in !GeoNetwork would have their !XLinks resolved when read from the database (takes place in XmlSerializer) - only resolved records are seen by users and harvesters
+  * Metadata Records in !GeoNetwork would have their !XLinks resolved when read from the database (takes place in !XmlSerializer) - only resolved records are seen by users and harvesters
   * Reindexing of metadata records that used to be done before servlet startup has been delayed until the servlet is up - this is to allow links between records in the local !GeoNetwork node to be resolved.
-  * The cache and the lucene index are kept in sync - XLink'd fragments that are held in the cache are eternal (they never time out) unless forced by a new admin operation which clears the cache and then rebuilds the lucene index for all records with XLinks (this operation can be scheduled or run immediately).  
+  * The cache and the lucene index are kept in sync - XLink'd fragments that are held in the cache are eternal (they never time out) unless forced by a new admin operation which clears the cache and then rebuilds the lucene index for all records with XLinks (this operation can be scheduled or run immediately). 
+  * XLinks and metadata records composed from xlink'd fragments can be made optional through the use of a system configuration option that can turn this feature on or off.
 
 Minor changes were required to the metadata editor so that metadata fragments are recognizable and cannot be edited. 
@@ -58 +59 @@
 === Backwards Compatibility Issues ===
 
-Metadata records as traditionally handled by !GeoNetwork should not be affected by the addition of this feature.
+Metadata records as traditionally handled by !GeoNetwork will not be affected by the addition of this feature.
 
-Effects on harvesters that harvest from !GeoNetwork: Composed metadata records will have their XLinks resolved before they are harvested as a harvester usually updates the set of records harvested from a remote site on a regular basis. If there was a requirement for composed metadata records to be harvested with unresolved XLinks then an option could be added to the harvester to prevent XLink resolution before harvesting.
+No issues for harvesters that harvest from !GeoNetwork: Composed metadata records will have their XLinks resolved before they are harvested as a harvester usually updates the set of records harvested from a remote site on a regular basis.
 
-Effects on export (eg. MEF): Composed metadata records exported as MEF files would have their XLinks resolved before export. If there was a requirement for composed metadata records to be exported with unresolved XLinks then an option could be added to the MEF export service to prevent XLink resolution before export.
-
-XLinks and metadata records composed from xlink'd fragments can be made optional through the use of a system configuration option that can turn this feature on or off. This has been implemented in the BlueNetMEST sandbox.
+No issues for export (eg. MEF): Composed metadata records exported as MEF files would have their XLinks resolved before export.
 
 == Risks ==
@@ -74 +73 @@
 }}}
 
- * This should (I think) be interpreted as a link to a fragment within the same document. From discussions with the deegree developers (who have an advanced xlink implementation in their WFS), it appears that some organisations are interpreting such a link as being a fragment in any document within the local database. (reference required).
+ * These are interpreted as a link to a metadata fragment within the same document. However, from discussions with the deegree developers (who have an advanced xlink implementation in their WFS), it appears that some organisations are interpreting such a link as being a fragment in any document within the local database?
 
  * Since this proposal and the fragment based harvester included allow xlink attributes on any element in the metadata record, composed metadata records with unresolved xlinks would fail validation. This is not an issue that is confined to composed metadata records though as !GeoNetwork does not provide any config options or other controls for the administrator to handle records that fail validation.