VDS Workset
===========

what *must* to be included into the VDS-1 prototype, and what is
a thing more destined for VDS-1.1 or VDS-2

1. VDS MUST includes
--------------------

o name spaces, required by Greg Graham
  - already defined in XML DTD

o "here scripts", required by Jim Annis
  - already defined in current XML DTD

o RefDB or similar CMS requirements; general CMS request
  - review Veronique's document
  - review Greg's comments on Veronique's document (BKComment)
  - partition RefDB into experiment specific and generic parts

o parameter sets, access at least one level group
  of parameters with one name, required by Greg Graham
  - may be related to RefDB work

o ((varargs) OR (lists AND ranges)), required by LIGO/Ewa
  - lists may be related to the "parameter sets" challenge

o extended transformation catalog
  - at least a feasible and easy to implement subset of the suggested
    transformation catalog.

o VDML (modification language)
  - XML DTD is specified

o VDAL (access and query language)
  - web service?
  - other (easier) kind of service for a prototype?

o finish XML definition
  - currently using XML DTD
    * easy syntax
    * no type checking
  - possibly using XML Schema
    * schemas are XML documents
    * improved type checking, constraints and recurrance specs
    * currently unknown to me :-(

o document XML definition


2. VDS nice-to-have for VDS-1.1
-------------------------------

o tri-model data, or access to virtually any 'object'
  - may be possible, if the object is accessible via an URL
    and can be encapsulated in web services
  - we should not limit ourselves to "just" tables, OBJY and
    files. Any URL-reachable web service may participate. 
  ==> URL access will lead to XML-RPC

o file equivalence
  - CMS insists on bitwise identical files at this stage

o catalog annotations
  - one could describe/comment pieces and store them.

o generators
  - might already be possible using XSLT on an XML template.

o type based transformation
  - first we need to capture types (what I shied away from), 
    before we can try to capture "generic recipes" for 
    transformation from one type to another type. While file 
    suffixes might work for a prototype