...
| model | description | considerations | status |
|---|---|---|---|
| sequential access | Streaming the FOXML in the order present on disk to the routines or code that does the migration. | This model minimizes memory usage and likely maximizes processing speed. It can also more easily force higher-level routines to acknowledge all content, preventing inadvertent lossyness. Complex higher-level routines would have to accept the data in the serialization order and couldn't easily alter processing based on content serialized deeper in the foxml datastream. | A proof-of-concept implementation has been written. |
| whole object access | Expose access to the whole object in some form. Pieces (like datastream content) would likely have to be accessed as needed from disk. | This model allows for more flexibility in higher level migration routines as content could be accessed in whatever order at the expense of a higher memory footprint and less coercion to consider every element within the original fedora 3 object. | An implementation of this is being built on top of the sequential access model. |
| versioned object abstraction | Fedora 3 allows versioning of datastreams but not object properties, though it does maintain a simple audit record of those object property updates. In migration scenarios where metadata from multiple sources (different datastreams or object properties) are to be represented in the Fedora 4 properties, it may make sense to have an abstraction representing a version of the fedora 3 object (and all its datastreams) in time. | This model would take care of a huge amount of the heavy lifting associated with version migration and the likely case where the DC datastream, RELS-EXT datastream and object properties would all find themselves represented as fedora 4 properties. | An implementation of this is being built on top of the whole object model. |
Implementation