#470 getIdAttribute not working correctly (on GeneProduct) - returns invalid SId

[Matthias König]

Hi all,
The getId attribute is not behaving correctly on GeneProducts in python (probably also on other SBases). If the SId is invalid an empty String should be returned, but currently the invalid SId is returned.

See description of the function (this was formerly behavior of getId):

        getIdAttribute(SBase self) -> string

        Returns the value of the 'id' attribute of this SBML object.

        Returns the id of this SBML object, if set and valid for this level
        and version of SBML an empty string otherwise.

Attached an example showing the issue. I am trying to read the Sids of the GeneProducts. Some of them are invalid, but still returned by getIdAttribute! e.g, G_N/A and G_Non-Enzymatic.

import libsbml

def example1():
    doc = libsbml.readSBMLFromFile("mitocore_updated_15_04.xml")  # type: libsbml.SBMLDocument
    model = doc.getModel()  # type: libsbml.Model
    model_fbc = model.getPlugin("fbc")

    for gp in model_fbc.getListOfGeneProducts():  # type: libsbml.GeneProduct
        print(f"<{gp.getIdAttribute()}>, <{gp.getId()}>")

if __name__ == "__main__":
    example1()

Actual output:

...
<G_ENSG00000139410>, <G_ENSG00000139410>
<G_Unknown>, <G_Unknown>
<G_ENSG00000168906>, <G_ENSG00000168906>
<G_N/A>, <G_N/A>
<G_ENSG00000168710>, <G_ENSG00000168710>
<G_ENSG00000158467>, <G_ENSG00000158467>
<G_ENSG00000101444>, <G_ENSG00000101444>
<G_ENSG00000156110>, <G_ENSG00000156110>
<G_ENSG00000160200>, <G_ENSG00000160200>
<G_ENSG00000116761>, <G_ENSG00000116761>
<G_ENSG00000129596>, <G_ENSG00000129596>
<G_Non-Enzymatic>, <G_Non-Enzymatic>
...

Expected output:

...
<G_ENSG00000139410>, <G_ENSG00000139410>
<G_Unknown>, <G_Unknown>
<G_ENSG00000168906>, <G_ENSG00000168906>
<>, <G_N/A>
<G_ENSG00000168710>, <G_ENSG00000168710>
<G_ENSG00000158467>, <G_ENSG00000158467>
<G_ENSG00000101444>, <G_ENSG00000101444>
<G_ENSG00000156110>, <G_ENSG00000156110>
<G_ENSG00000160200>, <G_ENSG00000160200>
<G_ENSG00000116761>, <G_ENSG00000116761>
<G_ENSG00000129596>, <G_ENSG00000129596>
<>, <G_Non-Enzymatic>
...

This could be incorrect behavior for getIdAttribute in general, but only checked this for GeneProducts.

I would need a workaround for this. Is there any function in libsbml which allows me to check if a string is a valid SId?

Best Matthias

[Lucian Smith]

The implementation of 'getIdAttribute' and 'getId' are actually identical: they both simply return the member variable 'mId'. So I'm not sure how you got different behavior for it, or what you're remembering happening. It does look like the documentation is misleading, and should be changed.

When you read in an invalid file like your example, libsbml has always (so far as I know) set any errors about what is invalid, but also usually goes ahead and saves the information from the file. That way, the user has the potential to use the incorrect information when fixing it to be correct again.

The upshot is that the function you want is SyntaxChecker::isValidSBMLSId(id). (You could also try to parse the error messages set on the document when it's read in, but that might be a bit overly complicated.)

[Matthias König]

Hi Lucian,
the behavior changed with latest releases.
You can still read the former behavior in the API docs, i.e. even the documentation of the function still states the old behavior (getIdAttribute):

Returns the id of this SBML object, if set and valid for this level
        and version of SBML an empty string otherwise.

If one called getId() on invalid SIds there was always an empty String returned! It was even impossible for me before to access invalid SBML ids because they were not even returned in former versions of libsbml. With libsbml-5.18.0 now suddenly invalid SIds are returned. This is a major change in behavior.
I assumed the old behavior was moved to getIdAttribute (which the API documentation suggests).

A lot of scripts of mine check for the empty strings on ids, which were returned in earlier versions.
M

[Matthias König]

Hi all,

sorry for the confusion. This issue can be closed and in the end was only a documentation error. I.e., I assumed the function did what the documentation says without ever checking that this was true ;).
Thanks a lot @luciansmith for all the help trying to find the problem.

Best Matthias