DSpace vs Xena

DSpace is now producing a xena file as part of its ingest process. Xena normalisation occurs in the InstallItem class, which is activated during the very last step in the DSpace process, after the DSpace editor has signed off on the submission. The implementation is not ideal, as I was forced to use the DSpace BitStream to write out to a temporary file, and then create a XenaInputSource using this temporary file. Ideally we would create a XenaInputSource using the BitStream directly, and this seemed to work well for the guessing stage, but the stream could not be read during the normalisation stage for some reason. So this is something to look at in the future.

The xena file is currently stored in a hard-coded directory on the server, so this will also need to be changed. The Sydney Uni guys want the xena file to appear in the "File in this item" list, like the following:

http://ses.library.usyd.edu.au/handle/2123/204

I think this means that the place where normalisation takes place will have to change, probably to the point where the ingested file is first received from the client and saved on the server. This way we can slip an extra BitStream into the process. This has the advantage of not having to worry about how to set up a separate Xena repository, as the xena files will be stored in the same way as the ingested files. Xena integration might be a bit harder though...