| Author | Topic |
Posts: 183
Registered: July 2008
|
|
Comp question: violating the 'fallback' rule
|
29 Jun '11 11:45
|
 |
|
One of the principles we established for the relationship between Level 3
core and Level 3 packages is that if you strip out the package
information, the remainder of the model must be syntactically valid, if
not semantically understandable.
If this principle was applied to packages, it would mean that if you had
multiple packages, and stripped just one of them, the remainder of the
model must again be syntactically valid.
As currently written, this is not true for 'comp', and I need your input
as to whether this is OK or not, and how I should structure validation
rules accordingly.
The issue is that I have Replacement and Deletion objects in comp that
need to point to other-package-defined constructs. As an example, if you
wanted to make a hierarchically composed spatial model, you would need to
be able to refer to the Geometry objects in the submodels, to say they
should be replaced or deleted.
So, assuming you referred to that Geometry object by its metaID, you might
have a ReplacedElement object that looked like:
<comp:replacedElement comp:metaIdRef="sphere1" comp:submodelRef="A" comp:identical="true"/>
The problem is that if you stripped out the spatial package information,
suddenly you are left with a dangling reference: 'sphere1' no longer
refers to anything you can parse.
In my opinion, it would make things entirely too complicated to do the
usual indirection we do to accomplish the 'fallback principle' for core.
Do you all agree? And if you do, how would you recommend I write the
validation rules for the 'metaIdRef' attribute?
-Lucian
____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
For a web interface to the sbml-discuss mailing list, visit
http://sbml.org/Forums/
For questions or feedback about the sbml-discuss list,
contact sbml-team@caltech.edu
|
|
|