/[volute]/trunk/projects/theory/snapdm/doc/Simulation Database Data Model-issues.txt
ViewVC logotype

Contents of /trunk/projects/theory/snapdm/doc/Simulation Database Data Model-issues.txt

Parent Directory Parent Directory | Revision Log Revision Log

Revision 305 - (show annotations)
Mon Apr 28 16:16:36 2008 UTC (13 years, 4 months ago) by gerard.lemson
File MIME type: text/plain
File size: 2025 byte(s)
added issues defined in conversation with Laurent
1 Issues
2 ------
4 - group of experiments with common goal/target using as "protocol" a way to use simulation codes.
6 - specialisation of parameter setting to string and numerical parameter settings
8 - input parameter class may have an enumerated list of possible values ala an enumerated data type
10 - move representationobjecttype under protocol and add "usage" version under experiment. i.e.
11 normalise the model further.
13 - we can generate XML schema root elements. Can be done by
14 - adding for example an <<entity>> sterotype.
15 - Or by taking all the concret (and therefore final) classes in an inheritance hierarchy that is not
16 contained.
17 - Or custom, based on the application.
18 Maybe last one is best.
20 - Quantity / Value : problem to serialize to DDL (class hierarchy)
21 => laurent proposes to have a simple Value (string for complex...) or DoubleValue
22 and move the unit to InputParameter & Property Classes and/or use a reference to a new SnapUnit enumeration (id, name, description)
24 - Issues form Skyp conv with Laurent:
25 . how do we identify SimDB resources and their constituents.
26 issues: we need to be able to use these to refer to them, inside a single SimDB, inside a single SimDB-XML,
27 across different XML docs, across SimDB instances. Or do we?
28 Really: need to write up the issues related to mapping references.
29 . need to know how to deal with values, quantities, units. should we add unit to property and parameter, possibly
30 overrridden on experiment? then can ignore unit on quantity, though we still want a numeric type to be able to
31 support numeric things.
32 . can we insist that all type names arwe unique within a model? if we are allowed to ignore full paths where this would be
33 a hinderance, this simplifies generation a lot
34 especially : JPA/discriminator column, table names, foreign key names etc etc
35 . do we need to update the set of primitive types for logical models? long/integer/short iso only integer?

ViewVC Help
Powered by ViewVC 1.1.26