Sign bank update script: schema version

[gregorydimitriadis]

The new global sign bank xml files look like so: (minus the spaces in front)

< ? xml version='1.0' encoding='utf-8'?>

< SIGNBANK DATA_VERSION='5.0' SCHEMA_VERSION='1.0' AUTHOR='BOSTON UNIVERSITY' DATE_CREATED='20200416' DATE_MODIFIED='20200416' REDIRECT='' >

The schema version describes the format of the xml file - if it is increased it means the format has changed in some backwards incompatible way, and Signstream (the app) needs to respond. It will deny opening any global sign bank file which has a version beyond the schema version it is capable of opening.

The values for min/max versions are stored in the settings.gradle file at the moment.

Make the logic which, upon parsing the sign bank file, will check its version against the known SS app sign bank schema version and deny if applicable.

[gregorydimitriadis]

Added to Todo milestone on zoom call with Chuck 2022-09-29

[cneidle]

If this change is made, it will also require a change to the script that checks, on launch, to ensure that the most current version of the Sign Bank is present, offering the user the choice of either upgrading the global Sign Bank or deleting it. It will need to do this only when a more recent version of the Sign Bank compatible with the current version of SignStream software is present.

HOWEVER, it should be noted that since changes are made to the Sign Bank content over. time, the less-than-current versions of the Sign Bank are not going to work properly anyway. I think we should keep the Sign Bank file format compatible, if at all possible. Perhaps it may be possible to add additional features that are readable only in newer versions of SignStream software, while ensuring that the Sign Bank file otherwise remains readable to prior versions of the software?? This is something that might be discussed with Augustine...

[cneidle]

related to #591

[cneidle]

I have discussed this with Augustine. We think that what makes sense is that, once we have revised the format of the Sign Bank files (and we should consult on what features should be included), we should, each time we upgrade the Sign Bank data on the DAI, release two versions of the Sign Bank file, one in the current format, and one in the newer format. The idea would be that those with versions of SignStream through the current version would check for upgrades as usual and upgrade latest version of the Sign Bank, if necessary, upon launch, exactly as they do now. But the newer versions of SignStream software would check.only for newer versions of the Sign Bank. That way, the data can be kept up-to-date for users of all versions of SignStream, with users of newer SS versions able to take advantage of newer features of the Sign Bank files. We can discuss further with Augustine, meeting perhaps towards the end of this month. Thanks.

[gregorydimitriadis]

Todo: not sure about the two sign bank version release - I think that might not be feasible. Version should be, though, moved to an X.Y.Z format, where X is backwards incompatible, Y is backwards compatible, Z is small bug fixes. So then, newer versions of Y could be installed as per usual, but newer X would be disallowed.

Est: 8 hours. This has many moving parts.

[douglas-motto-at-rutgers]

X is forward and backwards incompatible

[douglas-motto-at-rutgers]

assume older versions of X.Y formats to mean X.Y.0

[douglas-motto-at-rutgers]

Will need an agreement if multiple old major versions will be supported. Ex: version 3.Y.Z and 4.Y.Z. If so need a way to find the latest 3.Y.Z and 4.Y.Z versions.

If only the very latest will be published, then SS will only look for that one file.

Communicate with Augustine on this. Get his feedback.

[douglas-motto-at-rutgers]

Need messaging on when current file...

Is not the latest, and newer compatible version is available.

Is not the latest, but newer version is incompatible.

[cneidle]

Not sure what the problem is with maintaining two parallel sets of Sign Bank files. Over time, data in the sign bank changes, so it is important to have current data. Currently, all versions of SignStream thus far look for the sign bank file in some particular directory. At such time when we include additional information in the Sign Bank file, and have enhanced functionality in SignStream to deal with that information, we can just change the "Get Sign Bank" command to look for the Sign Bank in a new directory. Thus newer versions of the software will look for the newer format of the Sign Bank; older versions will continue to look for the Sign Bank where they look for it now. When we release new versions of the Sign Bank, we put one in each of those directories, with appropriate content and format. No? Changes in Sign Bank format should happen very rarely.

[gregorydimitriadis]

Discussed over emails - reiterating here:

The current situation with sign bank files is that the files have a DATA_VERSION as well as a SCHEMA_VERSION. The schema version would denote changes to the format of the file, where as the data version - which is the one getting updated as of now - changes when new data is added/edited to the file.

In the future at some point, the schema version might need to change to accommodate format changes, and a new SignStream version will need to come out in order to parse those new changes. At that time, the schema version might update to 2.0.0, and then a two-track approach would begin - such that SignStream versions which can parse 2.0.0 files will only update on version 2. files, and older versions would continue to update on 1. files, both being updated with new data versions as new data is added/edited. Files will be served from different locations/directories on the dai site.

Since the SignStream sign bank parser must change according to a format as of now undecided, it makes more sense to table this issue concerning altering the GetSignBank script until the time when that change occurs.

[douglas-motto-at-rutgers]

Just commenting that the SignBank SCHEMA_VERSION validation check within the SignStream application could be implemented independently of any changes to the way the SignBank file is generated, distributed or updated.

Such a version check should only require a small amount of time to implement, but be would be failsafe if someone tries to use "not the latest" version of SignStream (which they don't upgrade) with the "latest" version of the SignBank (which they do upgrade).

[douglas-motto-at-rutgers]

Given this issue is being shelved for now, I suggest moving out of this "jan/dec release" milestone and back into the "severe issues" milestone.

[gregorydimitriadis]

609 issue created to deal with the SgnStream aspects of this, and replacing it in the Dec/Jan 2023 milestone. This issue is being removed from the milestone and its severity as well.