Simulation Data Model Documentation
rwagner at physics.ucsd.edu
Thu Feb 14 01:31:34 PST 2008
> First, I am happy that this mailing list is active with many
> Besides, the simulation data model changed a lot thanks to Gerard and
> other contributors in a good way I think.
> Since last InterOp (end of september), the public documents about
> SNAP DM
> & protocol did not change at all,
> so I tried to use them & implement the SNAP DM for french simulations
> (galmer, horizon halo & galaxy catalogs, PDR...) and this work is
> going on.
> I want now to insist on one main point : SNAP documentation &
> change logs.
> Gerard changed SNAP pages to provide a new UML model, updated XML
> and a new online documentation appeared : great !
> However, does it imply that the previous reference document
> (SNAP_SimulationDM.doc) will not be updated anymore ?
> My concrete problem is to find differences between previous and
> versions of the SNAP DM.
> I purpose to use UML for what it is efficient = modelling.
> I mean the reference document for SNAP DM should be the UML model
> with the community edition of Magic Draw UML)
> and provided as a single xml file : SNAP Simulation DM.xml.
> I think that xml schemas & online documentation should be generated
> this xml document mainly by XSLT transformations
> or any other solution (maybe, ask help to DAL group) because it
> would be
> more accurate & easy to maintain.
> For now, the problem is that the UML project does not contain
> information :
> - short & long description of every entity (SNAPProtocol,
> SNAPExperiment ...)
> - cardinality of attributes & relations : optional or required
> & collections should be defined
> - UML model & xml schemas are not synchronized
> - xml schemas do not contain some classes (for example :
> SNAPPostProcessing hiearachy), but have detailled descriptions for
> entities & attributes
> So it is difficult to get descriptions and details of SNAP entities &
> because the information is spread out in UML document & xml schemas.
> Besides, it is hard to maintain manually those documents I think,
> that's why I purpose to use the UML model as the 'Reference'
> document with
> as much information as possible.
> Finally, a change log is needed to provide details on DM evolutions as
> Gerard begun to do it.
> Maybe, it could be generated too by a difference analysis tool...
I think the start of a solution to what you're suggesting a version
control system (Subversion gets my vote), and perhaps something like
a Trac site. This would give easy access to a change log, and a way
to compare versions. Both the NVO and AstroGrid use Trac and
Subversion, so I suspect someone would host the project. If not, I
will offer up space on our server.
Unfortunately, I am much less informed about UML, and the possible
conversion from XMI (the XML format for UML) to XML Schema.
More information about the theory