Is rule sbol3-10109 a problem for forward compatibility?

[jakebeal]

sbol3-10109 is a strong required rule that reads: "An object MUST NOT have properties in the “http://sbols.org/v3#” namespace other than those listed for its type or parent types in Table 21."

This seems to imply that is we add a new property, then any added property in say, an SBOL 3.1 file, will cause an SBOL 3.1 file to be considered invalid by an SBOL 3.0 tool. Is that something that we want?

[cjmyers]

This is how things worked in SBOL2, and it was a really important validation rule to avoid bugs. Before adding this rule, we had a lot of problems in the libraries with typos on tag names. With this validation rule, the libraries could not report these as errors, and we could fix the libraries/tools creating the improper SBOL. For these reasons, I would strongly oppose removing this validation rule.

You are correct though that an SBOL 3.0 tool will potentially be unhappy with an SBOL 3.1 file, depending on whether the library enforces this rule. In SBOL2, I believe libSBOLj was the only library that was strict on this rule. Therefore, many tools would accept the extra tags. Depending on the library implementation being used, this may or may not have been bad. Namely, if the extra tags get silently dropped, it would be bad. Assuming that most tools will be using one of our libraries, and the libraries are updated before the specifications are formally approved, then I think this is not too big an issue. Tools wanting to support a later version of SBOL 3.x would simply need to update their libraries.

Note this is very different than our backwards compatibility rules. Updating a tool that supports SBOL 3.0 to support SBOL 3.1 is simply a library update. If the tool does not care about the new tag, it simply just needs to round-trip it, which the libraries take care of. However, for major version upgrades, as we are well aware, these require complete overhauls of the tools.

[cjmyers]

Propose closing this issue.

[jakebeal]

I'd like to leave it open for a few more days to see if anybody else wants to weigh in. This question emerged from some discussion with @bbartley and @tcmitchell around implementation details of validation. @goksel or @udp might have something to say as well.

[tcmitchell]

Would changing this rule strong REQUIRED to a RECOMMENDED be a compromise solution? The description of RECOMMENDED says that if an SBOL document does not follow [a] rule, it is still valid SBOL, but it might have degraded functionality in some tools. Making this change would still allow the issue to be caught and reported. It would additionally allow flexibility across implementations to either ignore unexpected properties in the SBOL3 namespace or include them. The latter would allow implementations to be forward compatible with an added property in the SBOL3 namespace.

I genuinely don't care too much on which side of the fence this ultimately lands. I understand the arguments on both sides and find them both compelling.

[cjmyers]

Best practices have often been ignored, since the number of violations of these can be lengthy. There are also sometimes good reasons to ignore best practices. I think turning these types of errors into best practices would increase the time that these errors persist. These errors are really nasty, since they end up creating invalid SBOL files in the wild. So, I would still object to downgrading this error to a warning.

[jakebeal]

I think this one has sat long enough, and I'm fine to close it now.

[cjmyers]

I agree.