Forums

Hi Guys

Just throwing another thought into the discussion.

I making the assumption that a 'flattening' algorithm needs to deal with
packages whether it knows about them or not. It should essential just
copy or delete based on references and not care whether it understands
what it is copying/deleting.

If that is true then if a comp model was flattened BEFORE any
unrecognised packages were stripped the result should be a syntactically
valid model.

Could the 'must leave syntactically correct model' requirement in comp
be imposed as a post flattening requirement ??

Sarah

Of course, if the flattening algorithm has to know about packages that
it does not know about then we are all up the creek sans paddle :-)


On 29/06/2011 19:45, Lucian Smith wrote:
> 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
>


------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
sbml-comp mailing list
sbml-comp@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbml-comp