Table of Contents

  1. Release 2.0 - January 31, 2005
    1. Migrating from Fedora 1.2.1 to Fedora 2.0
    2. New Features
      1. Fedora Object XML (FOXML)
      2. Ingest and Export with Different XML Formats
      3. Relationship Metadata for Digital Objects
      4. Resource Index
      5. Batch Modify Utility
      6. Repository Administrator Reporting Tools
      7. Example Client for Making SOAP calls to Fedora APIs
      8. Third Party Library Upgrades
      9. Performance Tuning
      10. API-A and API-A-LITE Changes
      11. API-M Changes
      12. PID Definition Syntrax Relaxed
      13. Including PID as Default Parameter in Disseminations
      14. Syntax of Timestamp Values Extended
      15. Redesign of Fedora Web Site and Documentation
      16. Fedora Tutorials
    3. Bug Fixes
  2. Release 1.2.1 (Bug Fix Release) - April 19, 2004
  3. Release 1.2 - December 15, 2003
  4. Release 1.1.1 (Bug Fix Release) - September 5, 2003
  5. Release 1.1 (Bug Fix Release) - August 5, 2003
  6. Release 1.0 - May 16, 2003
  7. Release 0.9 - March 7, 2003
  8. Beta 1 - Dec 20, 2002
  9. Alpha 1 - Oct 31, 2002

1. Release 2.0 - January 31, 2005

Fedora 2.0 is a major release that culminates Phase I of the initial Fedora project that began in October 2001 and ended in October 2004. Fedora 2.0 includes significant new features and improvements including the introduction of the Fedora Object XML (FOXML) schema as the new internal storage format for objects, introduction of the Resource Index that provides enhanced search capability, introduction of a Batch Modify utility, upgrades of all third party libraries, performance enhancements, and a number of bug fixes.

IMPORTANT!! - Migrating From Fedora Release 1.2.1

Users migrating from Fedora Release 1.2.1 need to follow the steps outlined in the section entitled, Migrating From Fedora 1.2.1 to Fedora 2.0, and apply patch number 2 to their existing Fedora 1.2.1 repository BEFORE attempting migration to Fedora 2.0. Failure to do so can severely limit future migration options.

If you are running a version of the Fedora software prior to version 1.2.1, you will need to migrate your server software up to version 1.2.1 first, and then proceed with the migration from Fedora 1.2.1 to Fedora 2.0. Steps for migrating to Fedora 1.2.1 can be found in the release notes section for Fedora 1.2.1.

A. Migrating From Fedora 1.2.1 to Fedora 2.0

If you are upgrading from Fedora 1.2.1 to Fedora 2.0 follow these steps:

  1. Download patch number 2 from http://www.fedora.info/download/1.2.1/patch2.
  2. Make sure you are running v1.2.1 of the Fedora server software.

    DO NOT APPLY THIS PATCH TO ANY OTHER VERSION OF FEDORA!

    To check your repository's version, check the "describe" page. For instance, if you're running Fedora on localhost:8080, visit http://localhost:8080/fedora/describe

  3. Shut down your Fedora 1.2.1 server (using fedora-stop)
  4. Make a backup of the METSLikeExportDOSerializer.class file.

    Under Windows, make a backup of the following file:

    %FEDORA_HOME%\server\tomcat41\webapps\fedora\WEB-INF\classes\fedora\server\storage\translation\METSLikeExportDOSerializer.class
    

    Under Unix, make a backup of the following file:

    $FEDORA_HOME/server/tomcat41/webapps/fedora/WEB-INF/classes/fedora/server/storage/translation/METSLikeExportDOSerializer.class
    
  5. Copy the METSLikeExportDOSerializer.class from this patch into the above directory replacing the one there.

    Under Windows, copy the METSLikeExportDOSerializer.class from patch into the following directory

    %FEDORA_HOME%\server\tomcat41\webapps\fedora\WEB-INF\classes\fedora\server\storage\translation 
    

    OVER THE EXISTING FILE.

    Under Unix, copy the METSLikeExportDOSerializer.class from patch into the following directory

    $FEDORA_HOME/server/tomcat41/webapps/fedora/WEB-INF/classes/fedora/server/storage/translation 
    

    OVER THE EXISTING FILE.

  6. (OPTIONAL) If you installed the source code distribution of Fedora, you should also copy the included METSLikeExportDOSerializer.java file into your source directory.

    Under Windows, copy the METSLikeExportDOSerializer.java file from the patch into the following directory

    %FEDORA_HOME%\src\java\fedora\server\storage\translation
    

    OVER THE EXISTING FILE.

    Under Unix, copy the METSLikeExportDOSerializer.java file from the patch into the following directory

    $FEDORA_HOME/src/java/fedora/server/storage/translation
    

    OVER THE EXISTING FILE.

  7. Re-start your Fedora 1.2.1 server (using fedora-start). Your Fedora 1.2.1 repository is now ready for exporting its objects to the new server.
  8. Download the Fedora 2.0 software from http://www.fedora.info/download
  9. Install and configure the new Fedora 2.0 repository with a different host and port than the Fedora 1.2.1 server.
  10. Start the Fedora 2.0 server (using fedora-start).
  11. There are two ways to ingest objects from the 1.2.1 server: 1) use the admin GUI client to ingest the objects from the 1.2.1 repository or 2) use the fedora-ingest command-line utility to ingest the objects from the 1.2.1 repository
    1. Using the admin GUI client to ingest objects from the 1.2.1 repository
      1. Start the fedora admin GUI client (using fedora-admin).
      2. Under the File menu item, select File, Ingest, Object By Type, From Repository.
      3. Specify the hostname and port of the Fedora 1.2.1 server from which you want to ingest objects. Specify the administrator username and password for the 1.2.1 repository.
      4. Select all three object types including Behavior Definition, Behavior Mechanism, and Data object and click OK.
      5. The Fedora 2.0 server will now ingest all objects from the 1.2.1 repository.
      OR
    2. Using the fedora-ingest command-line utility to ingest objects from the 1.2.1 repository.
      1. Run the fedora-ingest command-line utility which is found in the client/bin directory.

        Under Windows, this file is found in:

        %FEDORA_HOME%\client\bin\fedora-ingest.bat
        

        Under Unix, this file is found in:

        $FEDORA_HOME/client/bin/fedora-ingest.sh
        
      2. Arguments for the fedora-ingest utility should include the following:
        • Type of ingest: specify R for repository
        • Hostname and port of the 1.2.1 repository from which you wish to ingest objects: source-host:source-port
        • Administrator username of the 1.2.1 repository: fedoraAdmin
        • Password for the administrator username of the 1.2.1 repository: fedoraAdmin is the default
        • Type of objects to ingest: specify DMO for all three object types.
        • Hostname and port of the 2.0 repository into which you are ingesting the objects: destination-host:destination-port
        • Administrator username of the 2.0 repository: fedoraAdmin
        • Password for the administrator username of the 2.0 repository: fedoraAdmin is the default
        • Log message: use "" for no message.

          For example:

          fedora-ingest r src-host:src-port fedoraAdmin fedoraAdmin DMO dest-host:dest-port fedoraAdmin fedoraAdmin ""
          
  12. After successfully ingesting all objects from the 1.2.1 repository, shutdown the 1.2.1 repository (using fedora-stop).
  13. If you desire to run the Fedora 2.0 repository under the same hostname and port as the 1.2.1 repository, you can now shutdown the 2.0 repository using fedora-stop, reconfigure the host and port in the fedora.fcfg file for the 2.0 repository to match those of the previous 1.2.1 repository, and restart the Fedora 2.0 repository.

B. New Features

  1. Fedora Object XML (FOXML)

    A new XML schema has been developed that provides a simple and unambiguous expression of the Fedora digital object model. Previously, Fedora digital objects could only be expressed in XML using an extension of the METS schema. FOXML is the new internal storage format for digital objects inside a Fedora repository. However, Fedora supports both METS and FOXML as ingest and export formats (see #2 below). The introduction of FOXML was motivated by several requirements: (1) simplicity - user feedback called for a conceptually easy mapping of the Fedora concepts to an XML format. Users wanted an obvious sense of how to create Fedora ingest files, especially those who are not familiar with formats such as METS and DIDL, (2) optimization and performance - the FOXML schema was designed to improve repository performance, both at ingest and during disseminations. Overall ingest performance has been positively affected with FOXML, especially in the validation phases, (3) flexibility - internal storage of FOXML enables easier evolution of functionality in the Fedora repository, without relying on Fedora-specific extensions to the METS schema. FOXML also introduces several new features to the Fedora Object Model including, the ability to store alternate identifiers for datastreams, and the ability to store format URIs for datastreams and objects (i.e., in anticipation of services such as the Global Digital Format Registry (GDRF). Refer to the user documentation for more details about FOXML and new features of the Fedora Object Model.

    The XML schema for FOXML is available at:

    http://www.fedora.info/definitions/1/0/foxml1-0.xsd

  2. Ingest and Export with Different XML Formats

    The Fedora project is committed to providing repository ingest and export functions that are compatible with community developed standards for digital object XML encoding. This is motivated by both interoperability and digital preservation concerns, where flexibility in the transmission format of digital objects is an important feature. In support of this, the ingest and export operations of API-M have been redesigned to allow submission and retrieval of digital objects in several alternative XML formats. In release 2.0, digital objects can be ingested and exported in either METS (Fedora extension) or FOXML. In future releases, we will add support for METS 1.3 and MPEG21/DIDL. Internally, the Fedora repository system provides a translation module that is responsible for mapping digital objects to the different supported formats. See the new "Ingest and Export Guide" in the system documentation for more details.

  3. Relationship Metadata for Digital Objects

    Fedora now supports the assertion of object-to-object relationships. Fedora digital objects can be related to other Fedora objects in many ways. For example there may be a Fedora object that represents a collection and other objects that are members of that collection. Also, it may be the case that one object is considered a part of another object, a derivation of another object, a description of another object, or even equivalent to another object. Relationship metadata of this sort can now be encoded in Fedora digital objects in a special reserved datastream (identified as "RELS-EXT"). Relationships are expressed as RDF/XML. Fedora provides a default relationship ontology that defines a set of common relationships (see: http://www.fedora.info/definitions/1/0/fedora-relsext-ontology.rdfs). Also, there is support for community or user-defined relationships. The relationships datastream is automatically indexed by Fedora as part of the new Resource Index module (described below), which provides RDF-based searching of the repository, including object-to-object relationships.

  4. Resource Index

    The Resource Index Module provides an RDF storage and query service for object metadata and relationships in Fedora. By default, the Resource Index indexes object properties, datastream, and dissemination information. In addition, user-defined, inter-object relationships expressed the RELS-EXT datastream are also automatically indexed. Examples of relationships between digital objects that may be expressed in the Resource Index include well-known management relationships such as the part-whole links between individual chapters and a book, and semantic relationships useful in digital library organization such as those expressed within the Functional Requirements for Bibliographic Records (FRBR). The query interface is exposed as a web service, providing the foundation for external services. Refer to the user documentation for additional information about the Resource Index.

  5. Batch Modify Utility

    A new utility has been added to the Fedora administrative client that allows repository administrators to perform object modifications in batch mode. The utility is built using the management API method of API-M so that most of the API-M methods can be run against groups of objects. The utility works by creating an xml-encoded input file of modify directives. This directives files is then processed in sequence to carry out the designated tasks. A sample batch modify directives file is included in the distribution in the batch-demo directory. Refer to the Batch Modify Utility user documentation for additional information regarding the Batch Modify Utility.

  6. Repository Administrator Reporting Tools

    A new Reporting interface has been added for obtaining simple administrative reports about objects in the repository. The interface consists of several static queries that can be performed on the repository to obtain statistics about objects. These queries currently include object counts based on type of object, creation date, and pid namespace. Refer to the user documentation for additional information.

  7. Example Client for Making SOAP calls to Fedora APIs

    A sample java client application is provided that demonstrates how to make SOAP calls to API-M and API-A. This client is written as a single java class that connects to a Fedora repository, and makes a set of successive set of SOAP calls to ingest an object from a FOXML XML file, then add datastreams, modify datastreams, export the object, and several other useful examples. It is intended as a quick and easy starting point for Java programmers who want to write their own clients to the Fedora SOAP interface. The demo client is found in the Fedora 2.0 distribution at: {FEDORA_HOME}/client/demo/soapclient. Programmers should examine the file DemoSOAPClient.java. To compile the demo, run the script named "compile-demo-soapclient.bat" (or .sh on unix). To run the demo, run the script named "run-demo-soapclient.bat" (or .sh on unix).

  8. Third party Library Upgrades

    All of the major third party libraries used in the Fedora codebase have been updated to reflect the most current stable versions available. This includes updating the underlying tomcat server to tomcat version 5. For Additional details regarding new library versions, refer to the license.html file in the distribution which has a complete list of the new libraries.

  9. Performance Tuning

    Significant enhancements have been made to the Fedora server code to improve ingest performance. These enhancements included both tuning of the underlying relational database as well as tuning how ingests are handled internally in the Fedora server.

  10. API-A and API-A-LITE Changes

    A general cleanup of the methods found in API-A and API-A-LITE has been done to provide better consistency between the SOAP-based and REST-based interfaces for API-A. The corresponding WSDL files have also been updated to reflect the changes.

    Previously in Fedora 1.2.1:

      API-A
      
        describeRepository
        findObjects
        getBehaviorDefinitions
        getBehaviorMethods
        getBehaviorMethodsXML
        getDissemination
        getObjectMethods
        getObjectProfile
        resumeFindObjects
     
      API-A-LITE
    
        describeRepository
        findObjects
        getDissemination
        getObjectProfile
        resumeFindObjects
        
    

    In Fedora 2.0:

      API-A
    
      describeRepository
      findObjects
      getDatastreamDissemination
      getDissemination
      getObjectHistory
      getObjectProfile
      listMethods
      listDatastreams
      resumeFindObjects
    
      API-A-LITE
    
      describeRepository
      findObjects
      getDatastreamDissemination
      getDissemination
      getObjectHistory
      getObjectProfile
      listDatastreams
      listMethods
      resumeFindObjects
      
    

    API-A Methods removed:

    • getBehaviorDefinitions - the functionality of this method is replaced with the revised getObjectProfile method which now provides complete object info including behavior definitions and methods.
    • getBehaviorMethods - the functionality of this method is replaced with the revised getObjectProfile method which now provides complete object info including behavior definitions and methods.
    • getBehaviorMethodsXML - the functionality of this method is replaced with the revised getObjectProfile method which now provides complete object info including behavior definitions and methods.
    • getObjectMethods - the functionality of this method is replaced with the revised getObjectProfile method which now provides complete object info including behavior definitions and methods.

    API-A Methods added or modified:

    • getDatastreamDissemination - this new method replaces the functionality provided in earlier releases using the getItem method of the Default Disseminator to return the contents of a datastream. Use of the default disseminator getItem method is now deprecated.
    • getObjectHistory - this new method provides a change history for a digital object listing each modification date when an object component has been modified. This is an interim solution to provide some basic information through API-A and API-A-LITE about the change history of an object. Eventually we would like to provide more detailed information from the Fedora audit records so one could obtain a detailed history of what changes were made to specific components of the object.
    • getObjectProfile - this method has been modified to return the complete object profile for a digital object. The object profile now includes all component information about an object.
    • listDatastreams - this new method replaces the functionality provided in earlier releases using the getItemIndex method of the Default Disseminator to list the datastreams of an object.
    • listMethods - this new method replaces the functionality provided in earlier releases using the getMethodIndex method of the Default Disseminator to list the methods of an object.
  11. API-M changes
    • logMessage parameter now exists on all object-modifying methods.
    • Datastream altIDs attribute. Any number of alternate identifiers can be specified for datastreams on creation or modification. This information is currently maintained, but not acted upon.
    • Datastream versionable attribute. A new boolean parameter that indicates whether Fedora should make changes in-place or retain prior versions on datastream modification. This information is currently maintained, but not acted upon.
    • New ingest method added. With the introduction of FOXML and support for multiple ingest formats, an additional parameter was required on ingest to specify the format of the file to be ingested. Valid values for format are "foxml1.0", "metslikefedora1", or "default". The format of "foxml1.0" specifies ingest files is encoded using FOXMLv1.0. The format of "metslikefedora1" specifies the encoding is Fedora's extension of METS. The format of "default" indicates to use the current repository default format. Refer to the API-M WSDL for additional information about the change. The former ingestObject method is now deprecated.
    • New export method added. With the introduction of FOXML and support for multiple export formats, an additional parameter was required on export to specify the format of the file to be exported and to specify the context of the export. Valid values for format are "foxml1.0", "metslikefedora1", or "default". Valid values for format are described above. Valid values for context are "public", "migrate", and "archive". A value of "public" produces an export file that is appropriate for use outside of the repository (all datastream content can be obtained via public callback URLs). A value of "migrate" produces an export file that is appropriate for migrating an object from one Fedora repository to another. A value of "archive" produces an export file that is a standalone entity, where all datastream content is inlines (XML inline and binary base64-encoded inline). Note that the "archive" option is not implemented in Fedora 2.0. Refer to the API-M WSDL for additional information about the change. The former exportObject method is now deprecated.
    • modifyDatastream now supports changing the mimeType and formatURI, and altID.
    • modifyDatastream and modifyDisseminator methods now support a "force" parameter, which indicates that even if a data type contract would be broken, Fedora should accept the change anyway.
    • purgeObject and purgeDatastream now include force parameters. Currently when specified as true, these throw an exception. This feature will be implemented in a future release.
    • Consistent parameter ordering. Parameter ordering of all the API-M methods was adjusted to make parameter ordering more consistent. Generally, the first one or two parameters identify the thing being accessed/modified (object PID, datastream or disseminator ID). When "logMessage" is relevant, it occurs just after any data parameters. When "force" is relevant, it occurs last.
    • The treatment of nulls versus empty strings in arguments for the modifyDatastream and modifyDisseminator methods of API-M is now more consistent. Arguments specified as null indicate that the original attribute of the component is to remain unchanged. Arguments specified as the empty string indicate the original attribute is to be set to the empty string. Arguments specified as non-null or non-empty indicate the original attribute is to be replaced by the specified value.

    Summary of API-M changes:

    • addDatastream: added parameters altIDs and logMessage
    • addDisseminator: added parameter logMessage; removed
    • parameters bDefLabel and bMechLabel
    • describeUser: [no change]
    • export: added parameters format, context
    • exportObject: [no change]
    • getDatastream: [no change]
    • getDatastreamHistory: [no change]
    • getDatastreams: [no change]
    • getDisseminator: [no change]
    • getDisseminatorHistory: [no change]
    • getDisseminators: [no change]
    • getNextPID: [no change]
    • getObjectXML: [no change]
    • ingest: added parameter format
    • ingestObject: [no change]
    • modifyDatastreamByReference: added parameters altIDs, versionable, MIMEType, and formatURI, and force
    • modifyDatastreamByValue: added parameters altIDs, versionable, MIMEType, formatURI, and force
    • modifyDisseminator: added parameter force; removed parameters bDefLabel and bMechLabel
    • modifyObject: [no change]
    • purgeDatastream: added parameters logMessage and force
    • purgeDisseminator: added parameter logMessage
    • purgeObject: added parameter force
    • setDatastreamState: [no change]
    • setDisseminatorState: [no change]
  12. PID Definition Syntax Relaxed

    Prior to Fedora version 2.0, the syntax for persistent identifiers (PIDs) was defined as a subset of the URN syntax, but was not strictly enforced by the server software. In version 2.0, the PID definition syntax has been relaxed to enable a wider range of possible PID values and the server software now strictly enforces the syntax of incoming PIDs.

    The following describes the syntactic constraints for PIDs in normalized form. The only differences with non-normalized PIDs are that the colon delimiter may be encoded as "%3a" or "%3A", and hex-digits may use lowercase [a-f].

      PID:
    Length : maximum 64
    Syntax : namespace-id ":" object-id namespace-id:
    Syntax : ( [A-Z] / [a-z] / [0-9] / "-" / "." ) 1+ object-id:
    Syntax : ( [A-Z] / [a-z] / [0-9] / "-" / "." / "~" / "_" / escaped-octet ) 1+
    escaped-octet: Syntax : "%" hex-digit hex-digit hex-digit: Syntax : [0-9] / [A-F]
  13. Including PID As Default Parameter in Disseminations

    When constructing complex user-defined disseminators that reference disseminations from other objects, it is often handy to be able to pass the PID of the data object on to the nested dissemination requests. Prior to Fedora 2.0, the only way to accomplish this was to add a formal User Parameter to the disseminator method and use it to pass the value of the PID. This syntax is awkward since the PID of the data object is already contained in the dissemination request. For example:

    http://localhost:8080/fedora/get/demo:999/demo:991/getMethod?userparm1=value&userparm2=value&pid=demo:999
    

    In the future, we plan to make it possible for the PID of the data object to be automatically passed as a parameter so it is always available downstream as a valid parameter on any dissemination request. As an interim solution to address this issue, Fedora 2.0 allows the PID of the data object to be passed as a default behavior mechanism parameter by using a special syntax of the DefaultInputParm element in the behavior mechanism object. For example:

    <fmm:DefaultInputParm defaultValue="$PID" label="The PID of the data object" parmName="PID" passBy="VALUE" required="true"/>
    

    Specifying a DefaultInputParm with a default value of "$PID" will result in the PID of the data object being passed on to the external service defined in the behavior mechanism object. In the WSDL section of the behavior mechanism object, reference the special DefaultInputParm as you would other parameters. For example:

      <wsdl:operation name="getService">
        <http:operation location="runScript.pl?pid=(PID)"/>
           .
           .
           .
      
    

    At run time, this will be translated into

      runScript.pl?pid=pid-of-the-data-object
    

    A similar syntax is available to pass the object URI of the data object. If you want to pass the data object's URI, then specify a DefaultInputParm with a default value of "$objuri" and this will be translated at run time into

    runScript.pl?pid=info:fedora:/pid-of-the-data-object
    

    where PID is the persistent identifier of the data object.

    The demo data object object named demo_SmileyStuff.xml and the associated behavior mechanism object named demo_DualResImageCollection.xml provide an example of the new syntax.

  14. Syntax Of Timestamp Values Extended

    Prior to Fedora 2.0, the syntax of timestamp values was to the nearest second. This range has been extended in Fedora 2.0 to include milliseconds to capture versioning changes that occur in less than one second. The new timestamp syntax is:

      YYYY-MM-DDTHH:MM:SS:SSSZ
      
      e.g., 2005-01-17T12:13:54:185Z
      
    
  15. Redesign of Fedora Web Site and Documentation

    The Fedora web site at http://www.fedora.info has been totally redesigned to provide enhanced readability, better navigation, and a more consistent "look and feel". Areas like the "Tools" section have been added to provide a place where Fedora users can share code and techniques they have developed using Fedora. The tools section is still under construction but will be available for accepting posts in the near future.

  16. Fedorial Tutorials

    A new series of tutorials is being developed that provides step-by-step instuctions for accomplishing common tasks with Fedora. The tutorials target a broad audience from system developers and repository managers to end users. Currently, there are three planned tutorials in the series:

    1. Introduction: Basic Concepts in Fedora
    2. Getting Started: Creating Fedora Objects and Using Disseminators
    3. Information Modeling: Designing Fedora Content Models
    As of Fedora 2.0, only the first two tutorials are available. The third tutorial is in progress and will be available in the spring of 2005. The tutorials can be found in the release in the tutorial directory under userdocs. The tutorials are also available on the web site at http://www.fedora.info/documentation/tutorials.shtml.

C. Bug Fixes

  1. Incorrect GMT Datetimes - Creation dates for objects do not appear to have the correct GMT timestamps. (Bugzilla #52)

    When objects were created, the GMT timestamps stored did not reflect the correct time of object creation. This was bug in fedora.server.utilitites.DateUtility. The time zone offset was incorrectly being applied to the creation datetime. Objects now reflect the correct GMT creation datetimestamp.

  2. Managed datastreams inadvertently deleted - Under certain situations managed content datastreams could be deleted when purging similarly PIDed objects. (Bugzilla #53)

    This was a bug in fedora.server.storage.replication.DefaultDOReplicator. Managed datastreams are stored internally using an identifier that consists of objPID + dsID + dsVerID. An errant regular expression was being greedy in matching which could result in similarly PIDed objects being deleted. The regular expression is fixed to prevent this from occuring.

  3. Errant space in SchemaLocation used by getnextPID - There is an erroneous space preceding the SchemaLocation in output for getNextPID. (Bugzilla #54)

    The SchemaLocation in the xml header output when running the getNextPID method of API-M and API-M-LITE contains an errant blank. This bug will only cause problems if trying to validate the xml output from the server. The errant space has been removed.

  4. Dublin Core description element missing from drop down menu in admin GUI client. (Bugzilla #55)

    The drop down menu for Dublin Core elements in the admin GUI does not contain the description element. The description element has been added to the drop down list.

  5. Unable to disseminate timestamped disseminations - Under certain situations, attempting timestamped disseminations would throw NullPointerException. (Bugzilla #56)

    This bug only occurs when attempting timestamped disseminations using user-defined disseminators (i.e., disseminators other than the default disseminator).

    This was a bug in fedora.server.storage.SimpleDOReader. When datastream state checking was added in Fedora 1.2, the section of code dealing with populating the DisseminationBindingInfo class did not include the new variable for datastream state. As a result this variable in the class is never initialized which leads to the eventual null pointer exception when attempting timestamped disseminations with user-defined disseminations.

  6. Serializer fails on export of bMech objects. Exporting bMech objects throws NullPointerException. (Bugzilla #57)

    The problem was that the method that checked WSDL and SERVICE-PROFILE datastreams for instances of the local pattern "http://local.fedora.server" did not have this pattern compiled. This caused a null pointer exception when the xml datastreams were searched for this pattern. Bmech objects now export correctly.

  7. Object Label updates not reflected in ObjectProfile - Changing an object's label in the admin GUI is not reflected when disseminating objectProfile. (Bugzilla #58)

    This was a bug in the replicator where the object label field was not being updated when the object label was changed in the object xml. Object label changes are now properly displayed when disseminating the objectProfile.

  8. Timestamp information not displayed in all views of Default Disseminator (Bugzilla #59)

    Timestamp information was not being properly handled by the XSL stylesheet that is used to style the output from viewItemIndex. This is now corrected and timestamp info is properly displayed in all views of the default disseminator (getObjectProfile, viewItemIndex, and viewMethodIndex).

  9. Date issues when Server and Client in different Timezones - Creation dates for objects can be incorrect when server and client are in different time zones. (Bugzilla #60)

    When a Fedora server is in one time zone and a Fedora client is in a different time zone, it was discovered that incorrect timestamps were displayed by the client when retrieving objects from the server.

    If you open the object editor on an existing object and go to the Datastreams pane, you will see that the created dates on the version timeline do not match what's in the datastream at the server.

    Even though the admin GUI client is getting the creation data from the server (via the java Calendar and Date classes), it appears that the client evaluation of the values considers the system clock current settings which are adjusted based on time zone. This is probably embedded in the underlying implementation of the java Calendar class.

    The fix was to redesign the handling of timestamp information by both the Fedora client and server. Fedora now standardizes on all dates PRODUCED by Fedora as STRINGS in ISO8601 format: mm-dd-yyThh:mm:ssZ. This allows Fedora to accept strings in mm-dd-yy or mm-dd-yyThh:mm:ss or mm-dd-yyThh:mm:ssZ format, to keep backward compatiability.

  10. Problem when versions get assigned the same timestamp (Bugzilla #64)

    In certain situations when modifications to an object component occur in rapid succession it was observed that a timestamp granularity of seconds was insufficient and you could have two versions with the same timestamp values to the nearest second. The solution was to extend the value of timestamps to include milliseconds to prevent any potential conflict.

  11. Inconsistent treatment of nulls versus empty string in arguments of modifyDatastream and modifyDisseminator methods of API-M (Bugzilla #68)

    The treatment of nulls versus empty strings in arguments for the modifyDatastream and modifyDisseminator methods of API-M is now more consistent. Arguments specified as null indicate that the original attribute of the component is to remain unchanged. Arguments specified as the empty string indicate the original attribute is to be set to the empty string. Arguments specified as non-null or non-empty indicate the original attribute is to be replaced by the specified value.

  12. Error when editing disseminator label when using McKoi (Bugzilla #76)

    When attempting to edit a disseminator's label when using McKoi as the underlying SQL database, the server would throw SQLException. This error was due to a typographical error in the database column name being used. Oracle and MySQL are case insensitive regarding column names, but McKoi is case sensitive. This allowed dissemination labels to work under MySQL or Oracle implementations, but fail with McKoi implementations. The case of the column name is now corrected and works for all three database implementations.

  13. Oracle error on ingest: cannot insert NULL into DSBIND.DS (Bugzilla #77)

    In certain situations when using Oracle as the underlying SQL database, ingest would fail with SQLException. The cause was attempting to insert NULL into the column dsBindKeySeq when no value was specified in the object for this optional value. Oracle does not allow NULL for this column type so the code has been modified to insert zero("0") when dsBindKeySeq is not specified in the object.

  14. Editing object label containing apostrophe throws SQLException (Bugzilla #82)

    When attempting to edit an object's label containing an apostrophe, the server responds with SQLException. The apostrophe character is a special character that must be properly escaped in SQL INSERT statements. Object labels are now checked for special characters and properly escaped before issuing the SQL INSERT command.

  15. Oracle char(1) column types return with space padding (bugzilla #85)

    It was observed that when using Oracle as the underlying SQL database, column types of char(1) would return with space padding which could result in errors downstream. This was not the case with McKoi or MySQL. The fix was to change the db schema column type to use varchar(1) instead of char(1) everywhere in the db schema.

  16. Object label containing ampersand character throws Exception when attempting to disseminate getObjectProfile method (bugzilla #86)

    It was observed that creating an object with a label containing the ampersand character would later cause the dissemination of the getObjectProfile method to fail. This resulted from special characters, like the ampersand character, not being properly escaped when written to dynamically generated xml served by Fedora. XML special characters are now properly escaped before being written to the outgoing xml stream so ampersands and other special xml characters can safely be included in object labels.

2. Release 1.2.1 (Bug Fix Release) - April 19, 2004

Fedora 1.2.1 provides fixes to several bugs that were reported by users of Fedora 1.2. The new release is backward compatible with Fedora 1.2 and contains no changes to the underlying database schema.

IMPORTANT!! - Migrating From Fedora Releases Prior to Fedora 1.2

Users wishing to migrate from releases prior to Fedora 1.2 need to follow the steps outlined in Release 1.2 - December 15, 2003 and migrate to version 1.2 BEFORE attempting migration to Fedora 1.2.1.

Migrating From Fedora 1.2 to Fedora 1.2.1

If you are upgrading from Fedora 1.2:

BUG FIXES:

1. Errors in installation document regarding source installations. (Bugzilla # 3)

The installation document has been updated to say that the JAVA_HOME environment variable must be set prior to installing the source distribution since ant requires this environment variable to perform the build. A typographical error regarding changing the permissions on the ant executables has been corrected to read: "This can be done with the command: chmod 755 $FEDORA_DEV/res/ant/bin/*."

2. Admin GUI client - Purge Failure error message text does not wrap. (Bugzilla # 5)

When an error is encountered while attempting to purge an object, the error message displayed in the message pane does not properly wrap and scrolls off the edge of the window. This has been modified to properly wrap the message text so the complete message is visible regardless of length.

3. Admin GUI client - Purging object does not close object paneI in ObjectEditor. (Bugzilla # 6)

When viewing an object using the ObjectEditor and then clicking the purge button, the object is removed from the repository, the object pane remains on the screen. The admin GUI client has been modified so that the object pane is now closed when the object is purged.

4. Admin GUI client - New Dialog Enhancement Request . (Bugzilla # 7)

In the New object creation dialog, one enters label text and content model text and clicks "create" to ingest the object. Pressing the ENTER key instead of clicking the "create" button has no affect. This has been changed so pressing the ENTER key now has the same result as clicking the "create" button on NewObjectDialog pane.

5. OAI day-granular "until" parm taken as midnight beginning that date. (Bugzilla # 9)

For OAI requests, the code interprets both "from" and "until" parms (which both have day-granularity) as meaning midnight beginning that date. This is correct for the "from" parm only. The day-granularity "until" parm should be interpreted as "23:59:59pm ending that date". That way, an OAI request with equal day-granular "from" and "until" parms will return records for that date. Changes have been made regarding the way that the OAI "until" date parm is handled when using "Day" granularity. If Day granularity is being used, the date value for the Until date parm is modified to be Day + 23:59:59. This means that when using Day granualrity, specifying the same Day for both "from" and "until" date parms will result in matching all dates between 00:00:00 and 23:59:59 on that day.

6. Admin GUI client - Export dialogs are incomplete under MAC OSX implementation. (Bugzilla # 10)

This problem shows up only on MACs in exports from an opened object. In contrast, the dialogs from both File and Export submenus (export one object, export by type) do work correctly, as with Windows. These correct cases are where the filename is selected programmatically (i.e., pid.xml). Exports from an opened object (either to export the object as xml or to export a datastream of the object) give dialog boxes which lack filename fields so the user has no opportunity to select the filename. Navigating with the dialogue to a directory with an existing file needs to match the needed mimetype, and selecting that file will result in overwriting that file's contents with either the object xml or the datastream contents, but without changing the filename. The JFileChooser dialog was not allowing entry of filenames in cases where that should be possible. The workaround was to, for these specific cases, default to the platform's native file dialog by using java.awt.FileDialog. Note that using the platform's native dialog is not a solution for all file dialog-related actions. JFileChooser still needs to be used in some cases because it has an option to only allow the choosing of directories, whereas FileDialog is limited in this regard.

7. Admin GUI client - Log file generated when ingesting objects by type is incorrectly persistent. (Bugzilla # 11)

When performing multiple ingest objects by type operations in the same admin client session, the log file displayed for subsequent ingest objects all show the log file from the initial ingest object operation. Closing the admin client between ingest object operations produces the expected results. This behavior is a result of the code checking to see if the log PrintStream is null to decide if a new log file is to be generated. If null, a new log is generated, otherwise it assumes there is an existing log to be displayed. Although the closeLog method in fedora.client.ingest.Ingest closes the log PrintStream(s_log), it does not get immediatley garbage collected so can have a non-null value for some time period after being closed. The code has been modified to explicitly set the PrintStream to null after being closed to resolve this issue.

8. Admin GUI client - After deleting disseminator using ObjectEditor, the bdef drop down list is not refreshed. (Bugzilla # 12)

If you open an existing object, delete a disseminator, then try to re-build the disseminator in the same session, the drop down list of behavior definitions does not include the bdef that was associated with the disseminator that was just deleted. If you exit the object editor after deleting the disseminator, then re-open the object in the editor, then the bdef becomes available again in the drop down. The code has been updated to refresh NewDisseminatorPane after a purge so the bdef used by the purged disseminator is visible once again in the drop down list of bdefs.

9. Fedora search not accepting underscores. (Bugzilla # 13)

The use of the underscore (_) character in Fedora searches generates an error that varies depending on the sql database being used. There was some obsolete code involving the syntax of the WHERE clause for Search queries where a special string " { escape '/'} " was appended to the end of any WHERE clause search string containing special characters that required escaping according to the SQL92 syntax rules. This code is no longer required and has been removed so underscores in searches no longer produce an error.

10. WSDL documentation - Inline wsdl docs for api-m.ingestObject mention incorrect state. (Bugzilla # 14)

The wsdl docs inside the Fedora-API-M.wsdl file say that upon ingest, an object's original state is "N", which is wrong. It should be "A". The comments in API-M.wsdl for ingestObject and createObject have been updated to reflect that the initial state of object is set to "A".

11. API-M addDisseminator method - addDisseminator method fails to update sql db when more than one pre-existing disseminator. (Bugzilla # 16)

When creating an object using the admin GUI client that has one or more existing disseminators, adding a new disseminator adds the disseminator to the object xml, but fails to properly replicate the disseminator in the sql database. This was a bug in DefaultDOReplicator that caused improper updating of the sql database in the case where a new disseminator was added to a data object, via the addDisseminator method of API-M, where the object had one or more pre-existing disseminator(s). The result was a mismatch between the xml representation of the object and the sql database representation. This problem has been corrected.

12.Admin GUI client - List of MIME types for XMLMetadata displays types other than text/xml when adding multiple datastreams. (Bugzilla # 17)

In the Admin GUI client, the MIME type drop down menu should only list text/xml when the XMLMetadata radio button is checked. This is true when the "new Datastream" button is clicked for the first datastream. However, if the datastream is saved, and another new datastream added, the MIME type list shows MIME types other than text/xml when the XMLMetadata radio button is checked. The code has been modified so that only MIME tpyes of text/xml are displayed for datastreams of type XMLMetadata.

14. Demo Objects - Label for DC datastream of demo object obj-ead-finding-aid.xml incorrect. (Bugzilla # 20)

The demo object (demo:17) for the Rita Mae Brown finding aid has an incorrect label when you do a viewItemIndex. The DC record's label is shown as "DC Record for Pavillion III Architectural image object" which is wrong. However, when you click on that link, the underlying xml looks correct. The label for demo object demo:17 has been corrected.

15. Search - resumeFindObjects skips next result in sequence. (Bugzilla # 21)

When displaying search results that spanned more than one screen, the search interface will skip over the first entry on the next screen. For example, if the maximum number of search hits to display is 10 and there are 30 hits, the search will display hits 1-10, then 12-21, and then 23-30 omitting hits 11 and 22. This was a bug in fedora.server.search.FiledSearchResultSQLImpl where the cursor in the ResultSet was being positioned incorrectly when there are more results to display than the specified maxResults value. The cursor is now correctly positioned and all hits are displayed.

16. Admin GUI client - Adding/removing datastream bindings in Admin GUI client result in broken disseminations. (Bugzilla # 24)

Removing and then re-adding a datastream binding in admin gui for a disseminator breaks the dissemination for that disseminator. XML representation of the object appears correct, but disseminations handled through sql database are broken. This was a bug in fedora.server.storage.DefaultDOReplicator that had to do with the improper updating of dsBind table when the binding map of an existing object was altered. The xml was correct after the update, but replication was incomplete on the sql database. The end result before the fix was an incomplete update of the dsBind table which had the effect of breaking disseminations for that object because of missing bindings in dsBind table. This has been corrected.

17. Admin GUI client -The state of datastreams is reset to Active in sql db when binding datastreams to a disseminator. (Bugzilla # 25)

If a datastream has a state other than Active and it is bound to a disseminator or if already bound and the binding is removed/re-added, the state of the associated datastream is reset in the sql db to Active. This was a bug in fedora.server.storage.DefaultDOReplicator that had to do with the updating of dsBind table when creating or modifying datastream bindings. The datastream state is correct in the xml, but the replication is incorrect in the sql database. Before the fix, the state of the updated bindings was always being set to "A" so if the state of a datastream was other than "A" and a binding that used that datastream was created/modified, the state in the sql database was reset to "A". The state of the datastream in the xml is now used to set the state when creating or updating a binding map. This guarantees that the state in dsBind table will always be the sameas that of datastream in xml.

18. Batch Utiltity - Sample mets-template.xml used in batch utility demo contains metadata wrapper errors. (Bugzilla # 25)

Some of the METS metadata wrapper elements in the mets-template.xml example file used with the batch utility are incorrect. e.g., administrative source metadata is in a techMD wrapper element. The typographical errors have been corrected in the sample template file.

19. Oracle open_cursor limit exceeded (Bugzilla # 29)

Users implementing Fedora with Oracle reported that the database would hang when attempting deletes of large numbers of objects. The database hang was the result of exceeding the open_cursor limit set by the database. This problem has only been reported with Oracle. There are apparently some subtle differences between the various JDBC drivers and how they handle cleanup when a ResultSet or Statement is closed. The JDBC code has been modified to better handle these variations and address the open_cursor problem for Oracle users.

20. FedoraMets ID lengths - ID lengths silently ignored. (Bugzilla # 30)

Fedora stores the definitive copy of objects as xml, but for performance also replicates a copy of objects in an sql database. With xml, there are no limitations on the length of attribute values or content. However, the sql database does impose field lengths which restrict the length of identifiers and labels. Users reported the truncation of some identifers in the sql database as a result of having identifier strings in the xml that exceeded the database schema field lengths. The xml validation code has been modified to verify the length of Fedora identifiers. Exceptions are now thrown at ingest time if any identifiers in the xml exceed the field lengths specified for those fields in the database schema. Currently, the validation is only applied to identifiers. Descriptive fields like labels, will be be truncated if they exceed the database schema field lengths. We will consider extending the validation checking to labels in the next release.

3. Release 1.2 - December 15, 2003

This new release contains a number of significant new features, including content versioning, the complete implementation of the Fedora Management interface, and major additions to the Fedora Administrator client to enable object creation and editing. With the advent of content versioning, the Fedora Access interfaces now support date-time stamped requests, so that a client can "go back in time" and see a digital object as it looked in the past. Additionally, this release provides a migration utility for mass export and mass ingest of objects from either directories or other repositories. The migration utility enables the moving of objects from older versions of Fedora repositories into the lastest version. It also is of general utility for copying or moving objects among repositories, for unloading repositories, and for bulk ingest of objects.

IMPORTANT!!! Upgrading From a Previous Release of Fedora

Although Fedora 1.2 is backward compatible with previous versions of Fedora at the interface definition level, there are changes to the underlying database schema that require digital objects to be migrated from an old Fedora installation to the new Fedora installation. If you want to keep digital objects from an old repository and migreate them to the new Fedora 1.2 repository, you must run the migration utility provided with Fedora 1.2. DO NOT INSTALL FEDORA 1.2 ON TOP OF THE PREVIOUS RELEASE. To upgrade from a previous release and migrate digital objects into the new repository follow these steps:

STEP 1 - INSTALLATION:

Follow the steps outlined in the Fedora Installation Guide. If you plan to migrate digital objects from a repository that is a previous version of Fedora, be sure to configure the new Fedora 1.2 installation to run in parallel to the existing installation. After the new Fedora 1.2 is installed, you will run a migration utility that will unload all objects from your old repository and ingest them into your new repository. If you are installing Fedora 1.2 on the same machine as a previous version, make sure to set the following configurations for the Fedora 1.2 installation:

1. install Fedora 1.2 into a different directory than the previous installation (set $FEDORA_HOME environment variable accordingly)

2. initialize a new database for Fedora 1.2 using the database configuration scripts which are set up with new defaults. If using MySQL, run mysql-config.bat (.sh for unix) with the new default database name of "fedora12" (or your own new database name that differs from the name used in your pre-existing Fedora installation. For McKoi, run the mkoi-init.bat (.sh for unix) which has a new default port number for Fedora 1.2.

3. set a different port for Fedora 1.2 to run on (fedoraServerPort in the Fedora config file fedora.fcfg)

4. set a different shutdown port for Fedora 1.2 (fedoraShutdownPort)

5. set a different redirect port for Fedora 1.2 (fedoraRedirectPort)

6. set a different storage path for digital objects (object_store_base)

7. set a different storage path for datastreams (datastream_store_base)

8. set a different storage path for temporary files (temp_store_base)

9. set the Fedora 1.2 repository to allow the PIDs from the old repository to be accepted (add namspaces to retainPIDs in fedora.fcfg)

10. if the OLD Fedora installation is running on a different machine, modify the fedora configuration file of the OLD Fedora installation to requests to be made by the new Fedora 1.2 repository. (Add IP address of Fedora 1.2 repository to allowHosts in fedora.fcfg of OLD repository.)

STEP 2 - MIGRATION:

Follow the instructions in the Fedora Migration Utility Guide. to migrate digital objects from your previous Fedora installation to the new Fedora 1.2 repository. The new repository migration utility is provided with Fedora 1.2 to easily perform a mass export and mass ingest of objects from the old repository to the new repository. The repository migration utility can copy or move objects among Fedora 1.1, Fedora 1.1.1, and Fedora 1.2 repositories. If you are upgrading from Fedora 1.0, please first upgrade to Fedora 1.1 before installing Fedora 1.2 since the migration utility does not work with Fedora 1.0.

NEW FEATURES:

1. Fedora Management Interface (fully implemented).

In Fedora 1.2 all operations of the Fedora management interface (API-M) are implemented. Operations for creating, modifying, inactivating, and deleting components of digital objects (i.e., Datastreams and Disseminators) are now available in the management web service via SOAP bindings.

2. Content Versioning.

The Fedora content versioning system is enabled with the release of Fedora 1.2. Now, any modifications made to a Datastream or Disseminator through the Fedora management interface (API-M) will automatically result in a new version of that Datastream or Disseminator being created by Fedora. The Fedora repository maintains all versions of all Datastreams and Disseminators, thereby creating a history of how objects change over time. Additionally, Fedora maintains an audit trail record of the nature of the object change events (e.g., who, what, when, why).

3. Fedora Administrator - Object Editor and Version Viewer.

The new content versioning features can be easily accessed via new menu items in the Fedora Administrator client. The new object editor features (i.e., File/New, File/Open) provide the ability to create and maintain digital objects through a graphical user interface. Using these menu items, the user can create a new digital object, as well as add/modify/delete Datastreams and Disseminators, and view the different versions of these components. For details see the Fedora Administrator Client documentation and the Fedora Content Versioning documentation.

4. Date-Time-stamped Access Requests.

Building on the capabilities of the new content versioning features, the Fedora repository will now support time-stamped disseminations and API-A requests. This enables a client accessing Fedora to be able to request a view of a digital object as it looked at a particular point in time. The syntax for using date-time in access requests is documented in the Client Documentation for API-A and API-A-Lite as well as in the WSDL API documents.

The algorithm Fedora uses to evaluate date-time-stamped requests is an "as of date" approach, meaning that the repository will return a view of content as it looked "as of" a particular date-time. The date-time stamp provided by the client is interpreted by Fedora as a "ceiling" threshold. As such, the repository will evaluate the version dates on Datastreams and Disseminators and return the view of content that is as close to the requested date-time without being greater than the requested date-time.

5. Migration Utility.

A new migration utility is provided to perform mass export and mass ingest of objects. At the core, the migration utility is built upon two newly enhanced command-line functions: fedora-export and fedora-ingest. Used together, these two command line functions can support a variety of scenarios involving moving or copying objects between repositories. The utility is general-purpose in that it can be used to copy or move objects among repositories for many reasons including upgrading from previous releases of Fedora. Client access to the migration comes in two forms: (1) run fedora-export and fedora-ingest at the command line, or (2) use the Fedora Administrator client to invoke these functions (see menu items File/Ingest and File/Export). Please consult the Fedora Migration Utility Guide. to learn how to use the new migration functionality.

6. Externally-generated PIDs Accepted by Repository.

A Fedora repository will now accept PIDs that are externally generated. To enable this feature, the repository administrator must modify the "retainPIDs" configuration variable in the Fedora repository configuration file (fedora.fcfg). The "retainPIDs" variable is a configurable parameter on the DOManager module. It defines the set of PID namespaces that the repository will retain during digital object ingest. If the repository receives an ingest request for a digital object, and a PID is provided (i.e., in the ingest XML), the PID will be accepted by the repository as the official PID of the digital object if the namespace of the PID is listed in the retainPIDs configuration variable. If the namespace is not found in the retainPIDs variable, the repository will generate a new PID for the digital object (and disregard any PID that may have been provided).

7. PID Generation via Management Interface (getNextPID).

In Fedora 1.2 the PID generation module has been exposed in the Fedora Management web service. Formerly, the PID generator was an internal module accessible only by other modules in the Fedora code base. Now, client can use the getNextID operation to request new PIDs from the repository. This is helpful in certain workflows where it is necessary to know ahead of time the PIDs of digital objects that are yet to be ingested into the repository, and there is a desire to have Fedora generate these PIDs. The getNextPID operation is part of the Fedora Management interface. At this time, the operation is exposed exclusively as a REST-oriented binding, meaning there is a specific URL syntax for requesting PIDs. See the WSDL API Documentation for API-M-Lite.

8. Fedora Administrator - Behavior Definition/Mechanism Builders.

A number of enhancements have been made to the Behavior Definition and Behavior Mechanism builders that are found within the Fedora Administrator client application (see the Builders menu).

a. Service profile for Behavior Mechanism Objects. A tab pane for entering metadata about the service that is represented by a Behavior Mechanism object is now available. The service profile metadata consists of information about the technologies that underlie the service, the valid input and output formats of the service, and other technical metadata.

b. Selection of behavior contract for a Behavior Mechanism Objects. A drop-down list of all the Behavior Definition objects in the connected repository is provided in the Behavior Mechanism builder. The user can select a Behavior Definition as the behavior contract when building Behavior Mechanism objects. The methods defined by the Behavior Definition objects are pre-loaded into the builder tool to assist in building a Behavior Mechanism object.

c. Various enhancements. Help buttons, better table entry for Dublin Core records, better management of dialog windows (e.g., no lost windows outside of main frame), minor bug fixes, and cosmetics.

9. Fedora Administrator - Batch Utility enhancement.

A log file is now produced for all output of the batch processing. Formerly, the results of batch processing initiated through Fedora Administrator were sent to the screen and could not be saved. Log files are deposited in a new directory at FEDORA_HOME/client/logs.

10. Fedora Administrator - Easier purge for multiple objects.

A minor enhancement has been made to the Repository Search/Browse tool that allows multiple objects to be selected from search results and to be purged without the user being required to enter a log message for each object. Now a single message can be entered for the whole set of objects, and the purge is activated over the whole selected set.

11. XML schemas for all Fedora-generated XML.

All XML formats that are used as to encode the results of Fedora API-A-LITE requests are now expressed as XML Schema. These schema files are located in the FEDORA_HOME\dist\server\xsd directory, and are also referenced in the schemaLocation attribute on the root element of Fedora XML responses.

BUG FIXES:

1. Ingest exception "unknown protocol c" in Windows XP.

Under rare conditions in some Windows XP installations, an obscure exception is thrown during object ingest that reports "unknown protocol c." This bug was traced to the digital object validation module, specifically in the Schematron validation phase (see DOValidatorSchematron.java). The problem had to do with instantiation of stylesheets. In previous versions of Fedora, the Schematron preprocessing stylesheet was configured in the repository using a local file path to a location in the Fedora server (see fedora.fcfg). In some of the XP installations of Fedora, the XSLT processor had problems instantiating an XSLT stylesheet whose input location was defined with a file path. The problem was fixed by ensuring that all stylesheets are instantiated in a StreamSource object via a URL instead of file path.

2. Failure on database connections with MySQL 3.23.53-3.23.58 on Windows.

In particular older versions of MySQL on the Windows platform there is a problem related to case sensitivity in database names that prevents database connections. Specifically, if a database is configured (e.g., via the Fedora mysql-config script) with a database name that is mixed upper and lower case characters, the database will not be recognizable at runtime. In these older versions of MySQL, the mixed case database name is accepted at configuration time, and loaded into the MySQL system tables. However, MySQL then creates the actual database directory on the filesystem with all lower case. Thus, at runtime, there is a mismatch between what's listed in the MySQL system table and what's on the file system. In these offending versions of MySQL, the database is not found due to this case sensitivity problem. The work-around for this is to use all lower case characters in the database name (e.g., "fedoraobjects" ) when performing the database configurations. However, since the problem is fixed in Windows MySQL 4.x and later, it is recommended that Fedora administrators install the latest production version of MySQL (currently 4.0.16).

3. Datastream size limit problem via Default Disseminator requests.

Access to Datastreams via the Default Disseminator methods could fail for very large Datastreams in repositories running with limited memory. The problem was traced to sections of code in DefaultBehaviorImpl where the Datastream content was being passed as a byte array instead of as an InputStream. All code now streams content via InputStream classes.

4. Concurrent ingest failure.

When two clients were simultaneously ingesting objects into a repository, an ingest failure would occur if the ingest requests hit the repository at exactly the same time. The exception reported by Fedora was that "temp-ingest already exists" which means that the temporary PID named "temp-ingest" was already in use. The problem was fixed by having all temporary PIDS appended with a date-time stamp, rendering them unique within a running repository instance. Now multiple concurrent client processes can run ingests against the repository.

5. ConcurrentModificationException on API-A-LITE.

This has shown up periodically when clients are running searches via API-A-LITE. The problem was traced to a part of the code that was cleaning up stale search sessions. Java throws a ConcurrentModificationException exception when you are iterating over something and trying to change it at the same time. The solution was to build a separate list of to-be-deleted items while iterating through the session list, and then, when finished, remove the appropriate items from the session list.

6. OAI provider service not escaping characters properly.

Fedora OAI provider service was not escaping internal entities (e.g., ampersands). For example, if the Dublin Core record contains an ampersand, the OAI output only produced a single ampersand character instead of the escaped encoding. This is now fixed and entities are properly escaped.

7. Dissemination of Inactive or Deleted Datastreams.

If a datastream had a non-active state, it was still able to be disseminated via API-A and API-A-Lite. Inactive or deleted datastreams are not intended to be exposed via the Fedora Access interfaces. However, inactive datastreams are always discoverable via the Fedora Management interface. In this new release, only active (state="A") datastreams will be exposed via API-A and API-A-Lite. If a dissemination is run that involves a non-active datastream, the repository will throw an exception and provide a meaningful message.

8. Possible Database Corruption as Result of Purging Objects.

Due to the way the relational database for the object cache was normalized, there was the potential for database corruption to occur in certain cases of purging objects. During purge, rows in the datastream binding map table could be inadvertently deleted during a purge object operation when there were still other objects depending on those rows. New referential integrity checks have been put into the database replication module to ensure that this will not occur.

9. DateTimeStamp Using 12 Hour Clock Schema.

The format being used to initialize the DateTimeStamp was using the 12-hour clock setting instead of the 24-hour clock setting. This is fixed now and all DateTimeStamp values use the 24-hour clock format.

10. API-A Not Functional With Example Soap Client When Running On Different Host (12/2)

If the example soap client was installed on a different host than the Fedora server, API-A requests would fail to display the transformed xml-to-html results. This was caused by a typographical error in the name of the stylesheet parameter in soapclient properties file that conveyed the Fedora server hostname. This is fixed now and example soap client can be run on any host.

11. Mckoi-stop.sh Ignoring FEDORA_JAVA_HOME

Mckoi-stop.sh script was ignoring environment variable for FEDORA_JAVA_HOME. This is fixed now.

12. FedoraAccessSOAPClient Returns ServletException When Disseminating Datastreams of Type "Redirected"

Attempts to disseminate datastreams that are of type "R' caused the soap client servlet to throw ServletException. This was caused by a ServletOutputStream being closed prematurely in FedoraAccessSOAPServlet. This is fixed now and Redirected datastreams can be disseminated using the soap client.

13. Minor Bug Fixes to BDef/BMech Builder

Reworked bmech builder class action listeners to keep bmech template object update in memory for every change to tabpane. This fixes bug where ds binding keys don't stay updated properly in pre-load of dsinput pane. Also, various other improvements in validation. Fixed bug where methodURL fields for the method being created did not property clean out when change among radio buttons occured (to change the URL from service base, to local service, to multiserver). Previously if you started things off with a service baseURL, then entered the baseURL, then changed to a LOCAL service or multi-server, the baseURL would still be hanging out in the method URL fields.

14. ListDatastreamIDs in FastDOReader returns ClassCastException

A Datastream data type was being erroneously cast as a String which caused the Exception. This has now been fixed so that ListDatastreamIDs returns the appropriate list of datastream IDs.

KNOWN ISSUES (and ways to avoid them):

1. Setting Object State on Ingest XML.

In a METS XML file used for ingest, object state is encoded on the RECORDSTATUS attribute of the METS header element. If this value is populated on the ingest file, the Fedora repository will accept it as is. Therefore, if the value of RECORDSTATUS is set to anything other than "A" (Active), the object will NOT be accessible via the Fedora Access interface. In other words, the object will not be considered active, and it will not be able to be disseminated. If objects are ingested in the inactive state, the state can be modified via the new object editor in the Fedora Administrator client (see menu item File/Open Object).

2. Bug in MySQL v4.0.12 on Linux causes database corruption.

The problem shows up only in Linux when running MySQL v4.0.12. Specifically, if a purgeDisseminator operation is run in the Fedora repository the problem is provoked. Normally, the purgeDisseminator operation removes a disseminator from a Fedora object XML store, and also initiates a replication process to make sure the disseminator is removed from the relational database object cache. Internal to the Fedora code, an SQL delete query is run via JDBC. The bug occurred when a the delete query was run. The query uses a where clause that should dependably evaluate to FALSE (i.e., "WHERE 1=2"), but in this particular version of MySQL under Linux, the query curiously and erroneously evaluates to TRUE. This particular query is intended to prevent certain rows from being deleted from the database. Instead rows are deleted resulting in referential integrity problems in the database. The solution to this problem is to upgrade to MySQL v4.0.14 or higher which does not have this bug!

3. Field Search via API-A (SOAP binding) not backwards compatible.

Due to a type definition change in the WSDL for API-A, the SOAP binding for the field search operation (i.e., findObjects) in not backward compatible across prior releases of Fedora. Thus, a search initiated via API-A (using SOAP) from a Fedora 1.2 client can not be fulfilled by a Fedora 1.1 or 1.0 server. In the WSDL for API-A, the findObjects operation defined a return type of fedora-types:FieldSearchResult (which is an array of fedora-types:ObjectFields). Formerly, fedora-types:ObjectFields defined an element named "locker." In Fedora 1.2, that element is now defined as "owner." Such interface changes are not accommodated by the Apache Axis library used to process SOAP requests. Fedora does not currently maintain different versions of its WSDL, so the change occurs in the "official" WSDL for the Fedora Access service. The problem can be bypassed by clients using the REST-oriented binding for the findObjects operation (see API-A-Lite in Fedora 1.2). The REST-oriented binding provides for a looser method binding, and allows the XML result be returned without type checking.

4. Behavior Mechanisms with SOAP Bindings Not Yet Supported.

(see release notes for Fedora 1.1).

4. Release 1.1.1 (Bug Fix Release) - September 5, 2003

Fedora 1.1.1 provides a fix for bugs detected by users of Fedora 1.1.

The new release is backward compatible with Fedora 1.1. If you are updating from an earlier release, please refer to the release notes for Fedora 1.1 regarding backward compatibility issues and new features introduced in Fedora 1.1

BUG FIXES:

1. SQL DB Corruption During Datastream Modification

The bug was an errant update query for the SQL database that when modifying a datastream it had the potential for corrupting the SQL database dsBind table. It only got introduced when attempting to modify a Datastream using the View/EditDatastream menu option in the admin GUI. With this fix, the modifyDatastream command is safe to use.

2. OAI-PMH Unicode Support

OAI-PMH interface was not sending the correct HTTP Content-type header value to indicate the character encoding of the XML, and as a result, the Servlet that provides OAI-PMH functionality was not properly encoding the output in UTF-8.

3. API-M Managed Content Modification

It is now possible to change a managed content datastream's label without changing its content. Previously, the API-M method, modifyDatastreamByReference required that something was provided for the DSLocation. Now, if DSLocation is passed in a null or empty, the original datastream content will be used (no change).

5. Release 1.1 (Bug Fix Release) - August 5, 2003

Fedora 1.1 provides fixes to several bugs that were detected by users of Fedora 1.0. It also provides a new API-A method ("describeRepository") that enables a client to obtain information about the repository server.

The new release is backward compatible with Fedora 1.0, with the exception of the Fedora server configuration file. If you are upgrading from Fedora 1.0, use you will need to enter your configuration values from the old Fedora 1.0 configuration file into the new configuration file provided with Fedora 1.1.

Aside from this, the Fedora 1.1 software is compatible with pre-existing digital objects created in Fedora 1.0. There is no need to re-create or convert existing digital objects. Fedora 1.1 can be configured to point at the existing file system location where Fedora 1.0 objects are stored, and to the existing relational database that contains information about the digital objects.

** REMEMBER: Do NOT use the Fedora 1.0 server configuration file (fedora.fcfg) with the new Fedora 1.1 release.

NEW FEATURES:

1. New API-A Method For Repository Info.

The API-A and API-A-LITE interfaces now define and implement the "describeRepository" request. This request will provide information about the repository server including repository name, version, base URL, and other attributes. The repository information can be obtained in either XML or HTML formats.

The API-A-LITE syntax is: http://yourhost:yourport/fedora/describe

2. Server Support For Self-Referential URLs.

The Fedora server now has internal support for avoiding breakage of self-referential URLs (i.e., URLs that contain the hostname and port of the Fedora server itself). This change allows the Fedora server host and port to be re-configured without breaking digital objects that contained URLs that referred to a previous host and port configuration. There are two places where self-referential URLs may exist: (1) in Behavior Mechanism Objects, where service bindings refer to a "local service" that runs within the repository server, and (2) in objects that contain a Datastream that references a dissemination of a digital object that is stored in the local repository.

3. New Source Code Revision Numbers.

Java Docs will now show the revision number generated from the Fedora CVS repository. These will not reflect the current Fedora software release number, but the actual version of the particular java source file. This will make it easier to determine whether a particular piece of code has changed from one Fedora release to another. For example, the source file FedoraAccessServlet.java has a release number of 1.58 as distributed within the Fedora 1.1 software.

4. Suppression of Messages in Standard Out.

All non-essential debugging and logging messages were removed from standard out. All meaningful server messages are now sent to the Fedora server log file.

5. Oracle 9i Support.

The Fedora server now has support for Oracle 9i. See Fedora system documentation for details..

BUG FIXES:

1. Failure of Batch Client Utility in UNIX Environment.

Specifically, a failure in running the Batch Build and Batch Build and Ingest menu items in the AdminGUI client when running the client in X-Windows. The batch utility could not correctly resolve file locations of object-specific files.

REPORTED ERROR: Recoverable error. java.net.UnknownHostException

FIX: The problem was traced to line 196 of fedora.client.batch.BatchXforms and has to do with the number of slashes in the file path (i.e., file:///). Solaris (and perhaps UNIX in general) wants only 2-trailing slashes instead of three. Places in the code where this has been a problem have been modified to ensure that any such URL strings are instantiated as a java.io.File object, then converted to a java.net.URI object. The URL string is finally obtained via the toString() method of the java.net.URI class. The strings generated in this manner are acceptable on both Windows and UNIX platforms.

2. Unable to Ingest Demo Objects when Fedora Server NOT on Port 8080.

The problem occurs because the METS xml files for the demo digital objects contain URLs that assume that the repository is running on port 8080. The URLs point to the location of the demo content that is served up by the local repository server.

REPORTED ERROR: [DefaultExternalContentManager] returned an error. The underlying error was a fedora.server.errors.StreamIOException The message was "Server returned a non-200 response code (404) from GET request of URL: http://localhost:8080/demo/batch-demo/thumb/americanacademy.jpg"

FIX: There are two kinds of demos that are affected: "batch demos" that are loaded via the batch tool and "local server demos." The content for the batch demos has been moved to www.fedora.info where it will always be available. The METS xml files for the batch demo objects now have URLs that point to the demo content at this stable location. The "local server demos" are intended to be run completely within the local server context (meaning a network connection is not necessary to run them). The content for these objects must, therefore, remain local to the Fedora server. A new command line utility called "fedora-convert-demos" is provided to convert demo object xml files to reference the currently configured host and port. If the Fedora repository is configured to a host and port other than the default of localhost:8080, the "fedora-convert-demos" utility should be run before ingesting local demo objects into the repository. The "fedora-convert-demos" is found in the FEDORA_HOME/client/bin/ directory. Instructions on running the utility can be found in the Client Documentation section of the system documentation.

3. Failure of Server Start-up when Running with Java 1.4.2.

The Fedora server fails during initialization of the DefaultAccess module. DefaultAccess tries to use a dependent module (DOManager) that has not yet been loaded by the Fedora server. The problem does NOT occur in Java 1.4.0 or 1.4.1.

REPORTED ERROR: Can't get a DOManager from Server.getModule

FIX: DefaultAccess is a server module, that itself needs access to other server modules. The DefaultAccess module initialization fails because DefaultAccess tries to access a dependent module (DOManager) that has not yet been loaded by the server. The problem is that server modules are not loaded in any particular order on server startup. Within any particular module's initModule method, you can't assume that ANY other modules are available from the server via the getModule(...) call. The solution is to move chunks of code like this to the postInitModule(...) method of the module in question. At THIS point in the server's lifecycle, you can assume that all modules have been loaded and are available via getModule(...), and that their initModule(...) methods have been called. Fedora server modules are listed in a HashMap. The reason that this problem showed up in Java 1.4.2 and not prior versions is that the order in which entries are put in a HashMap has changed in Java 1.4.2. It was just coincidence that the problem did not show up in prior Java versions (that loaded the HashMap in a different order.)

4. Hard-coding of Defaults for Server Host and Port.

There were several places in the Fedora 1.0 code base where the default host and port of the server was hard-coded as "localhost:8080". This required the repository administrator to make multiple changes when configuring a Fedora server to run on a different host or port.

FIX: All references to hostname and port are now driven off the fedoraServerHost and fedoraServerPort parameters in the Fedora server configuration file (fedora.fcfg). With this fix, a simple modification to these parameters and a re-starting the server is all that is necessary to change where the fedora server runs.

5. Fedora Shutdown and Redirect Ports Hard-coded.

The Fedora server shutdown and redirect ports were not configurable. They were hard-coded in the Tomcat server_template.xml file as "8005" and "8443" respectively.

FIX: These are now configurable in the Fedora server configuration file (fedora.fcfg).

6. OAI Identifier was NOT Configurable.

The repository domain name part of the OAI identifier was not configurable. It was hard-wired to be "fedora.info" which is not unique to a repository.

FIX: The Fedora server configuration file (fedora.fcfg) now has a repository domain name parameter in the OAI-PMH module.

KNOWN ISSUES:

1. Remote Password-protected Datastreams Need to be Redirected:

Fedora 1.0 and 1.1 servers are unable to mediate access to remote datastreams that are password-protected. Currently, Fedora provides IP restriction for its own interfaces (API-A and API-M). However, at this time, it does not handle backend security handshakes with remote servers. Thus, when a digital object makes reference to a datastream on a remote server and that server protects its content with HTTP Basic Authentication, Fedora will not be able to negotiate with the remote server to access that content. The way around this is to make sure that such datastreams are marked with as type R (Redirected Content). This is done in the METS XML file by setting OWNERID=R on the METS file element that used to encode the datastream.

2. Behavior Mechanisms with SOAP Bindings Not Yet Supported:

Fedora 1.0 and 1.1 servers cannot currently communicate with external web services that require the SOAP messaging protocol. This means that Behavior Mechanism Objects should not include WSDL that describes a service with SOAP bindings. In the current release, Fedora is able to communicate with web services that can be accessed via URLs using a simple HTTP GET (REST-style web services). The next release of Fedora will include a SOAP dispatching module which will enable the Fedora server to send SOAP requests to other services and receive SOAP responses from those services.

6. Release 1.0 - May 16, 2003

This release is the first public release of the Fedora repository system. Fedora is licensed under the Mozilla License. Refer to the README and COPYING files in the distribution for details of the license and restrictions governing copying and redistribution. This release includes some major changes since release 0.9 that include the following additions and enhancements.

1. Behavior Definition and Behavior Mechanism Object Builder

A new tool has been added to the Admin client that facilitates the building of behavior definition and behavior mechanism objects. The bdef/bmech builder provides a graphical user interface that greatly simplifies the task of creating behavior definition and behavior mechanism objects from scratch.

2. Additional Component Management Method Implemented

Several additional methods in API-M have been implemented. The new methods include

  • GetDatastream - retrieve the specified datastream

  • GetDisseminator - retrieve the specified disseminator

  • ListDatastreamIDs - obtain a list of datastream IDs

  • ListDisseminatorIDs - obtain a list of disseminator IDs

  • ModifyDatastreamExternal - change the pointer to a Referenced External Content datastream

  • ModifyDatastreamManagedContent - change the contents of a Managed Content datastream

  • ModifyDatastreamXMLMetadata - change the contents of an Implementor-Defined XML Metadata datastream

  • modifyDisseminator - modify the references to the behavior definition or behavior mechanism associated with the specified disseminator

3. Batch Utility Enhancements

The Batch Utility has been enhanced to make it less platform specific: all application files are now specified relative to the FEDORA_HOME environment variable. Also, a new tool has been added, combining build and ingest into a single step.

4. Documentation

The Fedora documentation now includes revised and enhanced Installation Guide, Release Notes, Manual, and Demos Guide. The Fedora manual includes a general introduction to the architecture, Installation Guide, User's Guide, and Developer's Guide. Upon successful installation, all documentation is also available through the userdocs webapp and can be access using the syntax:

http://hostname:port/userdocs

  • hostname - required hostname of the Fedora server.

  • port - required port number on which the Fedora server is running.

  • userdocs - a required parameter specifying the Fedora servlet path hostname - required hostname of the Fedora server.

In-line documentation in the source code has also been updated.

7. Release 0.9 - March 7, 2003

This release includes major changes since the December Beta1 release that include the following additions and enhancements.

1. Repository-Managed Content Datastreams

The implementation of Repository-Managed Content datastreams has been added. Repository-Managed Content is used for datastreams that are to be under the complete control of the Fedora repository. Upon ingestion, content that is referenced in the Fedora-METS "file" element is copied to an internal storage location in the Fedora server and the external pointer in the Fedora-METS object is updated to reflect the new internal storage location. Repository-Managed Content should be used in cases where it is desirable for datastream content to be stored and managed locally within the Fedora server. The repository manager must insure that there is sufficient disk space allocated to accommodate the ingestion of objects containing Repository-Managed Content.

2. Implementor-Defined XML Metadata Datastreams

The implementation of Implementor-Defined XML Metadata datastreams has been added. XMLMetadata datastreams represent user-defined XML-encoded metadata that is included in-line in the "amdSec" and "dmdSec" elements of the Fedora-Mets object. Although these datastreams are included in the metadata section of the Fedora-METS object, they can be disseminated just like the regular datastreams included in the "fileSec" element. Implementor-Defined XML Metadata datastreams should be used in cases where it is desirable to include user-defined metadata in-line in the Fedora-METS object. The Dublin Core metadata datastream is an example of an Implementor-Defined XML Metadata datastream (see Search Interface note).

3. API-A-Lite Interface

A new Fedora Access interface has been implemented known as API-A-Lite. API-A-Lite provides a streamlined implementation of the Fedora Access API over HTTP. The new interface provides two methods: GetDissemination, and GetObjectProfile. GetDissemination is used to request disseminations using HTTP. GetObjectProfile uses object reflection to provide a description of an object and its components.

4. Search Interface

The implementation of a new search interface has been added. Upon ingestion, metadata from the Fedora System Metadata section and the Dublin Core (DC) Metadata section of the object are indexed in a relational database, and may be searched using this interface. The DC Metadata section is an optional Implementor-Defined XML Metadata datastream in the object, where the "Datastream ID" is DC, and the XML conforms to the schema at: http://www.openarchives.org/OAI/2.0/oai_dc.xsd. If such a datastream is not provided, only the System Metadata will be indexed for that object. The search interface provides both simple and advanced searching via a web page included with the repository software. All queries are case insensitive. Simple search enables queries of words and phrases occurring anywhere in an object s indexed metadata fields. Advanced Search enables fielded searching across any combination of metadata elements using string comparison operators (= and ~) for string fields, and value comparison operators (  =, >, ≥, <, ≤  ) for date fields (dc:date fields may be treated as both). The wildcards, * and ? may be used in any string-based query.

5. OAI Provider Interface

The implementation of an OAI-PMH2.0 Provider interface has been added. OAI-PMH is a standard for sharing metadata across repositories. Currently, only the Dublin Core metadata for each object may be disseminated via this interface.

6. Access Control and Authentication

Although Access Control is not slated until year two of the project, the implementation of a simple form of access control has been added to provide a minimal level of security. IP range restriction is supported at both the Management API and the Access API exposures. The fedora.fcfg configuration file contains two new optional parameters in the Access and Management Modules named "allowhosts" and "denyhost" that are used to provide a comma delimited set of IP ranges. By default, the Management API is restricted to the IP address of the local host and the Access API is unrestricted. In addition, basic authentication is supported for API-M client-to-server communication. The client scripts and fedora-admin GUI have been modified to take a username and password at startup. Only one user, the super user "fedoraAdmin", is supported at this time. The password for fedoraAdmin is configured in fedora.fcfg.

7. Server Port Configuration

Server administrators can now more easily configure the port on which the Fedora server is exposed. The port is set in fedora.fcfg. Its default is 8080.

8. METS Extension

To accommodate some of the new functionality in Fedora, it was necessary to extend the METS schema. Fedora-METS objects are now validated against this extended version of METS. The extended schema, mets-fedora-ext.xsd, is available at dist/server/xsd/ and contains inline comments where changes were made. Other constraints for the objects, expressed in schematron, are available in the dist/server/schematron/ directory. The demonstration objects act as useful examples in understanding this schema.

9. Default Disseminator

The implementation of a new Default Disseminator has been added. Prior to this release, a data object could not be disseminated without first constructing and ingesting a behavior definition and behavior mechanism object. The Default Disseminator is a built-in internal disseminator on every object that provides an internal behavior mechanism for disseminating the basic contents of an object. The Default Disseminator does not replace Behavior Definition and Behavior Mechanism object. Instead, it provides a simple way for viewing the contents of an object without having to construct a separate Behavior Definition and Behavior Mechanism object. Behavior Definition and Behavior Mechanism objects are still required for creating disseminations that provide more complex sets of behaviors.

10. Storage Subsystem Enhancements

The code supporting the Java instantiation of Fedora Digital Objects inside the server has been re-worked so that serialization and deserialization are completely de-coupled from the Java interfaces to the objects: the DOReaders and DOWriters. Method names have also been changed to be more meaningful and consistent. The serialization and deserialization code has been modified to support the new version of the Fedora METS extension schema (described above). Overall, the code in this portion of the server is more compact and robust than in the previous version of the software.

11. Batch Ingest Tool Enhancements

The functionality to create and ingest batches of objects has been moved under the fedora-admin client tool. This consolidates administrative functions into a single tool and provides a readily accessible user interface. There are now more attributes which can be substituted, per-object, into the batch template. These include object label; datastream labels, both general and specific to a disseminator; and datastream title. An object comment can also be inserted.

12. New Demo Objects

This includes new demonstration objects. These objects can be loaded into the repository in one of two ways. The xml source files can be "ingested" into the repository via the Fedora Admin GUI client (from the command prompt, run: fedora-admin). Otherwise, they can be loaded with all other demos by running the demo load script (from the command prompt, run: fedora-demoall [hostname] [port] [username] [password]). The demo object source xml files for the demo objects can be found in the following directory: [FEDORA_HOME]/server/demo

There are two categories of demonstrations:

  • Local Server Demos - These demos can be run under any conditions. They are intended to work when the Fedora repository server is in a stand-alone condition, for example, if the repository is running without a network connection, or if the repository is behind a firewall and not set up to received outside connections.

  • Open Server Demos - These demos can only be run if the Fedora repository server is running as a network accessible server, meaning that it can make outgoing connections AND accept incoming connections. If the repository server is running behind a firewall, the firewall must be configured to allow incoming connections on the port that the repository server is running. The Open Server Demos use distributed content and services that are remote to the repository server.

Once demo objects are ingested into the repository, they can be viewed via a web browser using API-A-LITE or API-A. Remember the URL syntax to get the object profile via API-A-LITE is: http://{hostname}:{port}/fedora/get/{objectPID}

Example: http://localhost:8080/fedora/get/demo:5

For additional information refer to the demos.html file in the userdocs directory.

13. Documentation

After you have installed the software and started the server, you can access the documentation at http://localhost:8080/userdocs (substitute your own hostname and port number if using something other than the default).

8. Beta 1 - Dec 20, 2002

This release adds several important features to the Fedora software, including a batch ingest tool, parameterized disseminations, and datastream mediation. Digital object serialization and PID generation are now fully active, and validation has been enhanced. This is a non-public release.

1. Batch Ingest

A simple batch tool has been added, enabling the creation of a batch of objects conforming to the same content model. The tool consists of a 3 phase process. Phase 1 will take a directory structure consisting of datastreams and metadata and convert that information into an XML-encoded file. Phase 2 will then take the XML-encoded file and merge that with a object template file that specifies the content model being used to produce a Fedora METS-encoded file. Phase 3 of the process then ingests the METS-encoded files and returns a list of the PIDs that were assigned to the new objects. Phase 2 and Phase 3 are implemented in the beta1 release. Phase 1 will be implemented in the next release and is NOT available in the beta1 release.

2. PID Generation

PID generation has been activated. Upon ingestion, Fedora objects that pass validation are automatically assigned a unique persistent identifer or PID. The namespace prefix on the PID is determined by the namespace parameter in the fedora.cfg configuration file.

Special default PID namespace. To simplify initial setup and use of the repository, the default namespace of "test:" enables special handling of Fedora object PIDs. If the PID namespace is set to "test:" in the fedora/fcfg configuration file, the ingest method will NOT generate unique PIDs, but will instead use the PID values contained in the Fedora objects. This behavior occurs ONLY for the namespace of "test:". This feature was enabled to allow for easier loadeing of sample objects by novice users of the repository software.

3. Serialization

Objects are completely deserialized and re-serialed upon ingest. This has the effect that the stored version of the object (in METS form) will not be the same byte-for-byte as the version coming out, but the information will be preserved. It also enables more complete validation and PID generation.

4. Validation Enhancements

Two-phase validation of objects implemented. Upon ingestion, Fedora objects undergo a two phase validation process to validate against the Fedora METS schema and to validate against a set of rules defined for Fedora objects.

5. Parameters

Method Parameters enabled Method parameters can now be defined in Behavior Mechanism objects using WSDL providing a way to pass parameters to methods from the end user. For example, an image mechanism might have a method named getImage with parameters X and Y that specify the pixel dimensions of the requested image. Method parameters may be supplied by the end user on a dissemination request to affect the result of the dissemination.

Default Method Parameters enabled Mechanism designers can now create method parameters that are known only to the mechanism. Default method parameters cannot be altered by the end user and their values must be specified in the Behavior Mechanism object.

Enhancements to the example soap client (FedoraAccessSoapServlet) In the alpha1 release, the soap client enabled one to reflect on an object using GetBehaviorDefinitions and GetObjectMethods to display a list of all methods for a given object and to disseminate each of the methods. This interface has been enhanced to now allow for user input of method parameters for those methods that define parameters.

DB Schema updated A new table named MechDefaultParameter has been added and the datatype and length of some column names have changed.

6. Fedora Public Website

Added a release directory for downloading both milestone source builds and nightly binary distributions.

7. Datastream Mediation

To provide better security for the physical location of datastreams, a simple proxy has been implemented to disguise the location of datastreams to external mechanisms.

8. Sample Objects

The sample objects in the demo directory have been renamed for readability. The content of the objects has also been updated to reflect new additions like method parameters and default method parameters. The WSDL in the mrsid mechanism object in the alpha1 version contained errors that have been corrected. There is also a sample directory of image files and their associated metadata to create a batch of 10 image objects using the new batch tool.

9. Documentation

Enhanced in-line documentation in code. Ancillary documentation and diagrams updated. Master Specification Document updated. The Specification documented distributed in June 2002 has been updated to reflect changes.

9. Alpha 1 - Oct 31, 2002

Provided for the first time at the development/deployment team meeting at UVA, this release includes a basic server that can ingest objects, view objects in the repository, and export objects. This is a non-public release.

1. Management API

The management API is exposed via SOAP over HTTP and has the following methods implemented:

  • ingestObject

  • purgeObject

  • listObjectPIDs

  • exportObject

2. Management Client

The included GUI, Fedora Administrator, can be used to ingest objects, purge objects, view objects, and export objects. It also includes diagnostic consoles for API-M and API-A.

3. Access API

The access API is exposed via SOAP over HTTP and has the following methods implemented:

  • getBehaviorDefinitions

  • getBehaviorMethods

  • getBehaviorMethodsAsWSDL

  • getObjectMethods

  • getDissemination

4. Access Client

A java servlet is included with the server distribution that translates from pure HTTP requests to SOAP requests and provides an HTML interface so that object methods may be browsed and getDissemination requests can be provided without the need to send/recieve SOAP envelopes.

5. Object Validation

Objects must be validated according to METS schema rules, Fedora-imposed schema rules, and object integrity rules. For this release, the validation module implements the first two, but only METS schema validation has been activated.

6. Storage Subsystem

This has been implemented on top of a filesystem and a partially redundant database.