TestBed 0.4.0

Delivered on 2008-11-07

TestBed 0.4.0 provides the following new features:

A new webservice provides functionality for creating new objects from template objects. Refer to Object creation API for more information
A new webservice provides a shorthand for doing some queriefs that are often used in DOMS. Currently the service provides three features: Resolving whether a given PID is for an active object, finding objects that point to a given object using any relation, and finding all template objects for a given collection. Refer to Risearch API for more information. More methods can be added on request.
The TestBed now provides basic validation. Currently, only XML schema validation is done. Validation is done implicitly when changes an object's state to active. It is no longer possible to call methods that change an object, unless the object is inactive.
All schemas and XML datastreams are now valid.
The dc:title field of content models has been shortened a lot. The old longer descriptions are now in dc:description.
The ContentModel for ReelTape now has an example of an import method. The method is only a mockup, and will always return the same result, no matter what the bibnumber given.

What is still missing in TestBed?

Validation needs to be extended to validate relations and file formats (and possibly more)
Since the bit storage webservice has been deemed inadequate, a new service needs to be provided, that will work on local file paths and will automatically publish its results to a file object.
Search is still a mockup
We need an example of an export web service
Schemas need to be updated. Currently the following issues have been found that gives trouble for the GUI: Elements should preferably be simple types, substitutions groups may not be possible to implement correctly
We need to have a system for defining how to show an element in the GUI. Currently the following types have been identified: inputfield, textarea, uneditable
We need to have an example of a field with a controlled vocabulary in the test bed.
Some services depend on the user "fedoraAdmin" with password "fedoraAdminPass" to exist.

How does the TestBed differ from a final DOMS?

Apart from the missing bits mentioned above:

File Characterisation is still a mockup
User authorisation must be done against an LDAP
The final Fedora will be set up with a journaling module - the journaled Fedora should have XACML turned on
The bit storage web service will work on a true bitstorage. The current service works on local files.
The final DOMS is not accessible from localhost only
Summa integration