Forums

This is a fair point--practically, when you have comp structures that deal
with spatial objects, you don't need to worry about them if you don't
understand spatial because... well, because you don't understand spatial.

But there's still an implication for validation. If there's a package you
don't understand, and a reference you don't know about, do you assume that
the reference was correct, and pointed to an object in the package you
didn't parse? What if the modeler made a genuine mistake?

I'm gradually coming to the idea that a dangling reference is an error in
the spec, but can be a warning in a tool that doesn't understand all
packages.

-Lucian

* Frederic BOIS <Frederic.BOIS@ineris.fr> [2011-06-30 12:26] writes:
> That's what makes sense to me. That implies a hieararchical dependence
> between packages.
>
> >>> Nicolas Le Nov?re 29/06/11 18:09 >>>
> Could-it be solved by a propagating deletion? This part of comp package
>
> assumes that the submodels use spatial. I.e.the whole corresponding
> structure in the composed model would not mean anything without the
> spatial
> constructs. If we ignore the spatial package, we should also ignore all
> the
> construct in the other packages that refer to spatial constructs.
>
> On 29/06/11 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:
> >
> >
> >
> > 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
>
>
> --
> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>
> ____________________________________________________________
> 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
>
> ____________________________________________________________
> 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

This is a fair point--practically, when you have comp structures that deal
with spatial objects, you don't need to worry about them if you don't
understand spatial because... well, because you don't understand spatial.

But there's still an implication for validation. If there's a package you
don't understand, and a reference you don't know about, do you assume that
the reference was correct, and pointed to an object in the package you
didn't parse? What if the modeler made a genuine mistake?

I'm gradually coming to the idea that a dangling reference is an error in
the spec, but can be a warning in a tool that doesn't understand all
packages.

-Lucian

* Frederic BOIS <Frederic.BOIS@ineris.fr> [2011-06-30 12:26] writes:
> That's what makes sense to me. That implies a hieararchical dependence
> between packages.
>
> >>> Nicolas Le Nov?re 29/06/11 18:09 >>>
> Could-it be solved by a propagating deletion? This part of comp package
>
> assumes that the submodels use spatial. I.e.the whole corresponding
> structure in the composed model would not mean anything without the
> spatial
> constructs. If we ignore the spatial package, we should also ignore all
> the
> construct in the other packages that refer to spatial constructs.
>
> On 29/06/11 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:
> >
> >
> >
> > 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
>
>
> --
> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>
> ____________________________________________________________
> 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
>
> ____________________________________________________________
> 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
____________________________________________________________
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