Re: [sbml-comp] Thoughts about replacements and child elements

[Chris J. M. <my...@ec...>]

I agree with Sarah.  I find the whole idea of replacements and deletions on child elements very non-intuitive.  I think in most cases that it makes more sense to simply replace the parent object.  The resulting behavior is much more intuitive.  This feels like the strange things you can do in a programming language such as C which are clever but impossible to understand.  Therefore, I would advocate restricting the use of replacements and deletions to parent objects.  This should not really limit expressiveness, since you can simply replace/delete the parent instead, and it would make the result much more intuitive.  Eliminating such corner cases I think also helps developers who are considering supporting comp.

Cheers,

Chris

On Oct 7, 2013, at 2:26 AM, Sarah Keating <ske...@ca...> wrote:

> Hi Guys
> 
> Recently, whilst testing comp flattening with packages the following 
> started to trouble me:
> 
> Within the comp spec the recipe for creating the 'flat model' states 
> that if an element is replaced then the element being replaced is 
> removed from the flat model and any references to that element are 
> adjusted to point to the element it was replaced by.
> 
> That is totally intuitive when one is dealing with elements whose direct 
> parent is a model/modelDefinition (note I'm ignoring listOfXYZ elements) 
> such as Compartments/Species/Parameters etc.
> 
> However when one is looking at child elements whose direct parent is not 
> the model (e.g. SpeciesReference/KineticLaw in a Reaction or 
> Trigger/Priority/Delay/EventAssignment in an Event) it becomes slightly 
> more difficult to relate the idea of replacement with the actual 
> deletion that happens on flattening. When the object being replaced is 
> removed the parent of that object looses the information relating to 
> that object. This potentially changes the mathematics of the model - 
> which I know is what comp does BUT in using 'replacing' here that 
> achieves deletion it becomes a bit muddy.
> 
> Consider you have an Event (id=mainEvent) in your main model with a 
> Priority element and an Event (id=subEvent) in a submodel with a 
> Priority element. You add a comp:replacedBy element to the Priority in 
> your main model expressing that it should be replaced by the Priority 
> element from the Event in the submodel. When you flatten this model the 
> mainEvent will no longer have a priority element at all; since the 
> object to be replaced is removed.
> 
> I find this very counter-intuitive.
> 
> I accept (after brow beating Lucian about it) that this is what the 
> flattening recipe says will happen but I still have difficulty with the 
> concept.
> 
> So if you replace a speciesReference you lose that species from the 
> reaction; you replace a priority/delay/eventAssignment you lose that 
> part of your event description and there are cases in both qual and fbc 
> where similar situations arise.
> 
> 
> In fact there is no way I can actually "replace" [using the English 
> definition not the comp definition :-) ] any of the child elements I 
> listed - not within the scope of its parent.
> 
> Now I am not saying *I* want to do this. I can see it opens up a whole 
> new can of worms in terms of the flattening recipe - but the use of the 
> word replacement could lead people to believe that they can do this or 
> indeed that this is what they are doing.
> 
> Sarah
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp