Requirements for the ViPER-API

1. Ease of Use
   1. The API must use the three standard types, and verify the instance validity.
      1. File type: A descriptor specific to a media source file, there can be only one file descriptor instance per media source file. They can only have static attributes.
      2. Content type: A descriptor specific to a set of frames in a source file. There can only be one of a given declared type at a time in a source file, and they can only have static attributes.
      3. Object type: A descriptor for an object present in the video, or abstract idea, that allows dynamic attributes and multiple instances at any time.
   2. The API should try to keep to uniform naming conventions and keep with the standard Java conventions when possible.
   3. The system must maintain the current ease of use of the file format.
      1. The file format should be human readable.
      2. The implementation must be about as fast as the existing implementations of a metadata interface in the old (<v4) ViPER-GT and ViPER-PE.
2. A method to import data in the old format must exist
3. There must be a system for asking queries of a set of viper data.
   1. Queries must be allowed to be issued by data type, either viper type (Content/object/file), user type (Face, Information) or attribute datatype (lvalue, bbox, etc.).
   2. Must have method for queries by attribute value, or existance at a frame/on a clip.
   3. Must support complex queries by structure, e.g. all descriptors related to this descriptor, or all descriptors related to a descriptor related to itself.
4. The api must support sequences of video, clips, and collections of pages.
   1. The api must support loading video clips and jpegs.
   2. The api should support aggregating multiple jpegs into a sequence, or multiple clips into a movie, with a unified timespace.
5. The API must support editing the data.
   1. The api must support editing the configuration.
   2. The api must support editing the instances.
   3. The API must support event listeners for changes in the data.
6. Support for attribute datatypes
   1. There must be a set of standard included data types, matching the old system's set, as well as a 'Relation', or 'foreign key', attribute.
   2. There must be a system or method for adding new data types.
7. The API must support or enable undo/action history management.
8. The api must allow indexing by frame or by time.
9. The api should support relations between descriptors, beyond the simple datatypes
   1. The descriptor types should allow heirarchies.
   2. The heirarchies may allow inheritance of attribute types.
10. The API may support transactions.
11. The api should support generated attributes.
    1. The api should support simple generated attributes, such as implication from lvalues, default values, and implied null values.
    2. The api should support a scripting language that allows attributes to be calculated, as in a spreadsheet application.
    3. The api may allow generated descriptor instances.
12. Nonfunctional Requirements
    1. The API must provide a standard interface to ViPER metadata, in the form of java interfaces. We may decide to expand this to IDL.
    2. There should be an implementation that allows backing to a SQL database.
    3. The implementation must include a serializer/deserializer from XML.