From: Chris J. M. <my...@ec...> - 2013-10-01 14:08:32
|
Added the editors to this discussion and perhaps it should move to that list (or maybe discuss). I agree that this needs more discussion. My view has always been that maintaining validity after stripping a "required" package is very difficult, and I'm not sure it is worth the effort. While I understand the point of maybe a model may still mean something to someone without understanding the package, I really feel that the only compelling case for this is stripping layout/render in which required is false. In all other cases, if you strip the package, you really are left with a model for which you have lost important semantics. I wish we had decided that "required=true" means that a tool that loads a model with a package that it does not understand and is required that they are told to stop right there and throw an error. It is quite dangerous to go any further, in my opinion. Now, for the specific case of arrays, the good news is that assuming we provide a flatten routine in libsbml/jsbml then a software can actually easily convert an SBML file with Comp and Arrays into a model without these packages and then carry on with analysis. This is not true of other packages such as qual or FBC. All this being said, if we can come up with a reasonable way of keeping validity after stripping, I'm fine with it. However, I would prefer not to require that we come up with such a way, if it proves to be too difficult. Sarah, in another thread, you have argued about allowing flexibility for modelers, and I think this is the same issue. We should not put strong limitations on the arrays package simply to maintain validating after reduction as it makes the package less usable. Chris On Oct 1, 2013, at 4:53 AM, Sarah Keating <sar...@te...> wrote: > I'm with Lucian - in the sense that it would be nice to find a way to > have the constructs without violating a core validation rule. > > >>> Well, L3V2 would not require a model to be valid SBML after >>> removing a package, just valid XML. So, L3V2 would allow two >>> initial assignments to the same variable. > > That statement needs clarifying - L3V2 would allow two initial > assignments to the same variable ONLY if the original model had a > package that when stripped left it with two assignments to the same > variable. > > I think we need to be very careful about this ! > > It actually needs even further clarification - because it would only be > legitimate if the initial assignments contained elements/attributes from > the package that had been stripped. > > The relaxation of validity after reduction conversation has centred > around SIdRefs (ie the dangling reference issue). I don't think anyone > has actually said it wont matter if any of the validation rules no > longer hold. This is actually a wider discussion than I think we have > had as editors. > > From the point of view of some one validating a model where they do not > understand a package; if we say any core rule may be voided by a package > this would mean that the model must always be considered valid because > if you do not understand the package and it may have voided any core > rules - you just do not know anything anymore. I think this is a step > too far ... > > 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-arrays mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-arrays |