libCOMBINE requires modified dates for each OmexDescription. Is this necessary?
jonrkarr opened this issue · comments
the modification date is one of the attributes that people felt to have captured in the limited metadata subset, that was included:
I'm not sure what you would like to change. In the example:
https://github.com/sbmlteam/libCombine/blob/master/examples/python/createArchiveExample.py
the metadata element is created (without explicit call to modified), and so the current date is entered.
This is a minor issue. I noticed this a few months ago. I only reported it when I noticed the other real bug.
OMEX data model
My interpretation is that the created and modified dates refer to the content itself, rather than to the description of the content. The specifications don't seem to describe the purpose. Is this interpretation correct?
Use case
When I build a COMBINE archive, say from including a file I downloaded from a journal article, I don't necessarily know when the file was last modified. In this case, I want there to be no annotated modified date -- meaning, I have no information about when the file as modified (more precisely that I don't know exactly when the file was modified).
Strange behavior of libCOMBINE
Having a default modified date is fine. Typically, default are applied by the constructor when the object is created. This would then afford developers the opportunity to override the default when the object is constructed or afterwards.
libCOMBINE's behavior is different. When desc=OmexDescription() is constructed, len(desc.getModified()) is 0. Even explicitly running desc.setModified([]) doesn't prevent a default modified date from being added later. The default date is added when the XML representation is generated. This behavior mixes up the data model for OMEX with its serialization to XML.
I think a more conventional design would be for the default updated date to be applied during the instantiation of OmexDescription. Unfortunately, this change could be disruptive to others who are assuming that there's no modified date at construction and then add a modified date, resulting in two modified dates.
One way to accommodate existing users would be to keep track of whether the modified date has been set or appended. In this case, a date shouldn't be added during the serialization to XML.
I'm happy to change the behavior, such that no default modified date is generated. That way calling libraries have full control over whether there should or shouldn't be a modified date and if what it should be. Would that work for you?
That would be great.
this has been resolved