Forums

salis> So here's a practical question to get the
salis> discussion on something useful: What happens when a
salis> program receives an SBML file that it can't fully
salis> read? Well, what happens now (there are plenty of
salis> programs out there that either do not support SBML
salis> or only support certain parts of it)? I think a
salis> good answer is that a warning should be issued to
salis> the user (as suggested by Ralph and others). The
salis> user can then decide whether he can manually fix
salis> the problem or switch to some other software.
salis>
salis> But, imo, a bad solution is to start ostracizing
salis> developers who only support certain aspects of SBML
salis> and not others. What purpose does this serve?

I actually agree on this point.

I think the best practical way of addressing this issue is
to define degrees of SBML compliance, and to make the
definitions operational via validation suites. Then the
meaning of "SBML compliant" can be made more objective and
specific. The feature-set granularity could be controlled
by subdividing the test suite in some agreed-upon way.

(The word "compliant" may connote too-strong a sense of
obeyance and exclusion; I mean it in the sense of following
convention, not in the sense of toeing a party line.)

This would enable software developers to provide consistent
information to users about the degree of comformance of
their tools, and users could find out whether a given tool
supports the features they need. Users could also verify
the feature-set conformance for themselves if they wanted
to, thereby keeping developers honest :-).

Initially, there will probably be only one complete SBML
validation suite, making the distinction "SBML compliant" vs
non-compliant rather binary, but this may change, depending
on people's experiences and needs and the evolution of
sensible middle grounds.

MH