Menu
▾
▴
#360 Allow l3v1 packages in l3v2 documents to inherit 'id' and 'name'?
closed
nobody
5
2022-07-13
2019-02-12
No
With the clarification of SBML namespaces in https://sourceforge.net/p/sbml/sbml-specifications/358/, it might be possible to relax a restriction currently in L3v2. This is the current text:
"Any object class in an SBML Level 3 Version 1 package that inherits from SBase will not inherit the new id and name attributes on SBase." (p21, top).
I think it would not actually impact l3v1 packages used in l3v2 documents to allow them to have 'id' and 'name', and might, in fact, be helpful in some situations. It would not affect any element that already had a defined 'id' and 'name', since those elements already allow 'id' as well as 'package:id' (under the new system). I think it would also make the schemas simpler, though Sarah would have to confirm this. (Right now, an l3v2 document with an l3v1 package must define two SBases; one that core uses, and a different one that the package uses.)
This change would not affect any existing models, since 'not using an id or name' is still legal. It would just allow some things to have ids/names that currently do not. It would also not affect any models that do use 'id' and 'name' in the package namespace: they are still allowed, as well (with or without the namespace prefix).
Here is what I propose we change this text to, if others are OK with relaxing the restriction:
"Any object class in an SBML Level 3 Version 1 package that inherits from SBase will inherit the new id and name attributes from SBase when used in a Version 2 document in the same way they inherited the metaid attribute in a Version 1 document. Any package class that already defined an id or name attribute for itself behaves as it did before."
I highly support this. For me it would make life much easier if I know every SBML object I encounter will be a "real" SBase with id and name field.
This would be impossible to capture in a schema :-)
Just to clarify why I say this will not be captured by schema. Its not impossible but puts an onus on whatever is used to apply the schema validation.
At present the schemas define SBaseV1 - which contains annotaion/notes/metaid/sboTerm. L3V1 core plus all L3V1 packages inherit from this.
The schemas also define SBaseV2 - which in addition to the above contains id and name. L3V2 core inherits from this. Because of this change the L3V2 schema is a completely different document. At present there are no packages defined that use this version of SBase.
If we say that any package appearing in an L3V2 document inherits SBaseV2 we would actually need to create alternative versions of each package schema depending on whether they occur in an L3V2 document or an L3V1 document - but you could not determine this on the package namespace - you would have to determine it based on the core namespace.
Example: A file
<sbml fbc:required="false" xmlns:fbc="http://www.sbml.org/sbml/level3/version1/fbc/version2" xmlns="http://www.sbml.org/sbml/level3/version1/core" version="1" level="3"></sbml>
knows it needs to apply l3v1core schema and fbcl3v1v2 schema.
and
<sbml fbc:required="false" xmlns:fbc="http://www.sbml.org/sbml/level3/version1/fbc/version2" xmlns="http://www.sbml.org/sbml/level3/version2/core" version="2" level="3"></sbml>
knows it needs to apply l3v2core schema and fbcl3v1v2 schema.
In these cases it reads the namespaces and applies the appropriate schema.
If you do as suggested, i.e. let fbc inherit from l3v2 sbase there would need to be an fbcl3v1v2_altforl3v2 schema
schema validation would need to read the namespaces
apply the core ns
and then based on which core ns chose between
fbcl3v1v2 or fbcl3v1v2_altforl3v2
Not impossible but not particularly consistent with schema validation.
Not my call but my 2 cents.
This is hard to wrap my head around. After Sarah's explanation the issue became clearer, but I am clearly no expert here. It seems that a relaxation would create a lot of issues with the schema validation.
For me it seems like this has to be solved on the package level, i.e., the package must say if it has SBaseV1 or SbaseV2 parent classes (and the respective id behavior). It looks like the package xlmns is the place which would indicate this.
I.e.
xmlns:fbc="http://www.sbml.org/sbml/level3/version1/fbc/version2
is the fbc-v2 package which has SBaseV1 behavior
xmlns:fbc="http://www.sbml.org/sbml/level3/version2/fbc/version2
is the fbc-v2 package which has SBaseV2 behavior.
I don't think it is possible to relax this in the core specification (even if I really like the idea of everything having ids out of the box).
Clearly, I am not an expert in this issue either. The libsbml implementations of packages released with core L3V2 have already adopted alternative methods to retrieve id and name attributes from the SBase in L3V2 in stead of mId or mName attributes in the package own classes. It looks to me like that alterforl3v2 schemas for packages are in similar situation and could be a good solution. If I am right and adding alternative package schemas is practical, I would agree with Lucian's suggestion to relax the restriction.
This might need an in-person discussion at HARMONY with the editors and Sarah. Sheriff and Claudia, if you have any opinions, pipe up now ;-)
The advantage of doing this is that we get id and name on existing packages used in l3v2. The cost is that it makes the schemas more complicated than they are already.
Another option is to do what 'distrib' is doing for future versions of packages, where the package itself adds 'id' and 'name' to every element it defines, making it seamlessly compatible with both l3v1 and l3v2. Unfortunately, that doesn't fix existing releases/versions of packages.
At the 2019 HARMONY meeting, we decided this was probably a version-level change instead of a release-level change, meaning we could potentially make the change for l3v3, if that was a thing. Leaving the issue open for now.
We agreed to postpone the change. In the mean while, I do not think the change will have any real impact. The id and name attributes will be checked by core validator (validation rules described in the core spec) or schema because they do not have package namespace associated. Therefore they should be valid as long as the corresponding sbml core namespace is right (say l3v2 or l2v3) in the model.
Moved to https://github.com/sbmlteam/sbml-specifications/issues/358