Issues
------

- group of experiments with common goal/target using as "protocol" a way to use simulation codes.

- specialisation of parameter setting to string and numerical parameter settings

- input parameter class may have an enumerated list of possible values  ala an enumerated data type

- move representationobjecttype under protocol and add "usage" version under experiment. i.e.
normalise the model further.

- we can generate XML schema root elements. Can be done by 
  - adding for example an <<entity>> sterotype.
  - Or by taking all the concret (and therefore final) classes in an inheritance hierarchy that is not 
    contained. 
  - Or custom, based on the application.
Maybe last one is best.

- Quantity / Value : problem to serialize to DDL (class hierarchy)
    => laurent proposes to have a simple Value (string for complex...) or DoubleValue 
                and move the unit to InputParameter & Property Classes and/or use a reference to a new SnapUnit enumeration (id, name, description)

- Issues form Skyp conv with Laurent:
  . how do we identify SimDB resources and their constituents.
    issues: we need to be able to use these to refer to them, inside a single SimDB, inside a single SimDB-XML,
    across different XML docs, across SimDB instances. Or do we?
    Really: need to write up the issues related to mapping references.
  . need to know how to deal with values, quantities, units. should we add unit to property and parameter, possibly
  overrridden on experiment? then can ignore unit on quantity, though we still want a numeric type to be able to
  support numeric things.
  . can we insist that all type names arwe unique within a model? if we are allowed to ignore full paths where this would be 
  a hinderance, this simplifies generation a lot
  especially : JPA/discriminator column, table names, foreign key names etc etc  
  . do we need to update the set of primitive types for logical models? long/integer/short iso only integer?