SignStream disallowing opening Sign Bank files beyond possible schema version

[gregorydimitriadis]

Spinning off from #557 (edited from previous incorrect linked issue)

The linked issue above is dealing with the script aspects of this, while this issue will deal with the SignStream aspect.

SignStream will disallow opening of sign bank files in its local directories if the schema version is beyond what it is capable of parsing. This will be checked on opening SignStream and display a message to the user if necessary.

[douglas-motto-at-rutgers]

So a bit of weird behavior happens. For example...

When SignStream can interpret version 1.x.x, but the SignBank file is schema version 2.0.0...

-On opening SS it correctly reports the new signbank file can not be read, and SS should be updated. -But the main menu shows "Install SignBank file"...although one is already installed and presumed to be the latest. -Creating a gloss...the "Search SignBank" button appears. Clicking it reports an error that the file doesn't exist.

This doesn't seem cohesive. I'm not exactly sure what behavior should happen here...but the 2nd and 3rd items about seem wrong.

[douglas-motto-at-rutgers]

If the SignBank file is older than what SS works with, then similar weirdness happens too. For example...

When SignStream can interpret version 2.x.x, but the SignBank file is schema version 1.0.0...

-On opening SS it correctly reports the new signbank file can not be read, and the SignBank should be updated. -But the main menu shows "Install SignBank file"...although one is already installed. -Creating a gloss...the "Search SignBank" button appears. Clicking it reports an error that the file doesn't exist.

Again...This doesn't seem cohesive. I'm not exactly sure what behavior should happen here...but the 2nd and 3rd items about seem wrong.

[gregorydimitriadis]

Made these changes:

• The menu option now says "Install/Update ASLLRP Sign Bank..." to avoid any confusion there
• When the sign bank schema version is too high, instead of "Install/Update" being showed, it now correctly shows "Uninstall" as the only option
• The "Search Sign Bank" button on the Morph Phon window now is disabled unless the sign bank was parsed.

[cneidle]

Thanks.  Just one question:  are you considering the possibility that there may be a local but not a global sign bank when disabling the Search Sign Bank option?  Thanks. Sent from my iPhone; please excuse typos.On Feb 10, 2023, at 11:34 AM, Greg Dimitriadis @.***> wrote: Made these changes:

The menu option now says "Install/Update ASLLRP Sign Bank..." to avoid any confusion there When the sign bank schema version is too high, instead of "Install/Update" being showed, it now correctly shows "Uninstall" as the only option The "Search Sign Bank" button on the Morph Phon window now is disabled unless the sign bank was parsed.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[gregorydimitriadis]

Thanks.  Just one question:  are you considering the possibility that there may be a local but not a global sign bank when disabling the Search Sign Bank option?

Currently no - even before, it would be assuming that the global and local sign bank files were of the same version (by only looking at the global's version). This would probably have to be accounted for going forward - I think a separate issue to look at that in the future would be appropriate.

So if the global file schema version is too high, the local file will also not be parsed.

[cneidle]

This is an important issue.  A researcher storing their own data in a local sign bank should not lose all of it because the global sign bank has been updated…So we should be sure to come back to this. Thanks. Sent from my iPhone; please excuse typos.On Feb 10, 2023, at 12:02 PM, Greg Dimitriadis @.***> wrote:

Thanks.  Just one question:  are you considering the possibility that there may be a local but not a global sign bank when disabling the Search Sign Bank option?

Currently no - even before, it would be assuming that the global and local sign bank files were of the same version (by only looking at the global's version). This would probably have to be accounted for going forward - I think a separate issue to look at that in the future would be appropriate. So if the global file schema version is too high, the local file will also not be parsed.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[douglas-motto-at-rutgers]

@gregorydimitriadis The latest 2/10/2023 version is giving an error opening a signbank of version 1.5....it should not be giving such an error because it can open version 1.0 fine.

[douglas-motto-at-rutgers]

@gregorydimitriadis If an unreadable global signbank exists....and you disable the "Search Sign Bank" button...you can no longer search your readable local signbank file.

If the global is unreadable, but the local is still readable...the local should still be searchable.

[douglas-motto-at-rutgers]

@gregorydimitriadis Seconding Carol's concerns above. There's a lot going on here that can become tangled and broken.

Not sure if everything is fixable at this time given the time allotted and other priorities.

Need to think about if there's anything that exists in this version of SS that would prevent a real fix in a later version of SS

[gregorydimitriadis]

To clarify: the (current) disabling of the sign bank button is equivalent in effect to the (previously) blank contents of the sign bank upon being searched -- if this scenario were to happen (where the sign bank was not parsed).

[cneidle]

Just to clarify: It should be possible for a user to decline to use the Global Sign Bank, but to add entries to a Local Sign Bank. (Not everyone wants to use our annotation conventions.) Can you confirm that this is possible? It should be, and it should remain possible. THANKS. [For such users, the ability to delete and edit items in the local sign bank is essential, but that is a separate issue.]

[gregorydimitriadis]

@cneidle I will be working on this a bit more in order to address this - such that the global and local signbank files are processed separately and these messages would be shown independently, in such case where it occurs. (And ensuring existing local files would be accessible even when the global is not)

A separate question, however. The way I implemented this thus far is that the "can current signstream parse the current sign bank?" check occurs BEFORE the "is current sign bank file outdated?" check. So if a global file was in the signbank directory which had a schema version beyond what SignStream is capable of parsing, it wouldn't open, and it wouldn't check for new files from the DAI either (because they'd just be further advanced).

What we could change it to instead is to reverse the order of the checks, so it would check for outdated (and go through all those motions of updating signbank, restarting signtream, etc) but even after doing that it would still give the message about being unable to open it because it can't parse. it. The message would then say that SignStream needs to update.

Which way is preferred?

[cneidle]

Hi,

I’m not totally sure I understand the extensive focus on this scenario.

I don’t frankly see how the user could end up with a global (ASLLRP) Sign Bank version that is beyond what the version of SignStream that they are using could parse.

Presumably, people will only get a global Sign Bank file as part of the installation process, in which case they will end up with the appropriate version. Or if they launch the program and the Sign Bank file has been updated (for their version of the software), they will be forced to update to the appropriate newer version or to delete the global Sign Bank before SIgnStream launches.

We discussed having two parallel Sign Bank versions, older and newer format, both of which get updated in parallel with newer data. When one gets updated, the other also does.
So, the installation/update process will search the appropriate directory.

So, when SignStream opens, it warns the user if the version they have needs to be updated (for the version of SignStream they are using). That should only update the globalSign Bank file; it should leave the local Sign Bank file alone.

So SignStream should always be able to parse the global Sign Bank file that is present in the SignStream directory (if there is one).

I understand the desire to do a check, just in case… in case someone copied a Global Sign Bank file from a more recent version of the program directly into the Sign Bank subdirectory, but I can’t imagine why/how anyone would do that.

So having a SignBank file more recent than the version of the software can parse should never happen.

I don’t see why you need to de-activate the Search Sign Bank button.

If there is no global sign bank that has been parsed, there will be no results. Search Sign Bank should attempt to search both the global sign bank file (if there is one), and the local sign bank file (if there is one) -- which may not be in the newest Sign Bank format.

So, I’m not sure I understand what you are asking…

I also don't know if the potential difference in format poses a problem for displaying the results of a Sign Bank search through the two different sign banks.

Thanks, Carol

[cneidle]

I don't think this is the highest priority for Sign Bank issues, since we are far from having a new version of the Sign Bank file. Augustine has other higher priorities right now for DAI Sign Bank stuff.

The highest priority as I see it for Sign Bank is to make sure that the local Sign Bank works properly. This would include the ability to delete entries, since otherwise, errors in entry that are detected cannot be addressed. This is a real problem for using the local sign bank. cf. #621

The next highest priority (only because it is a harder problem to solve) would be dealing with the name sign issues, also discussed in other tickets. Name sign should not be a sign type. Things associated with radio buttons are sign types. As you suggested in another ticket, name sign should be an additional property. The incorrect status of name sign is causing a wide range of problems. Until we can revise the coding scheme and sign bank format, it would be great if there can be a work-around to properly identify both sign type and name sign status as an add-on. cf. #606 #607 #650

[douglas-motto-at-rutgers]

Or if they launch the program and the Sign Bank file has been updated (for their version of the software), they will be forced to update to the appropriate newer version or to delete the global Sign Bank before SIgnStream launches.

Currently there is no "for their version of the software".

The latest version available is universal across all SignStream application versions...major and minor.

Currently the SignStream application doesn't know that the "latest" version if downloaded may not be readable in that version of SS.

Making SignStream look for only the "latest" version that it can "open" would alleviate the situation.

[cneidle]

This discussion is obviously intended for the future.

When we do create a new format for the sign bank, we have proposed to have that available in a separate subdirectory, which would be accessed only by future versions of the software that are able to read those future-format files.

There would be parallel uploads of all new SignBank files to the the current subdirectory — readable by older (including current) versions of SignStream; and a new subdirectory, readable only by future version of SignStream. The data updates will have to be replicated in both folders whenever a new version of the Sign Bank file will be generated in the future.

On Feb 14, 2023, at 11:54 AM, douglas-motto-at-rutgers @.***> wrote:

Or if they launch the program and the Sign Bank file has been updated (for their version of the software), they will be forced to update to the appropriate newer version or to delete the global Sign Bank before SIgnStream launches.

Currently there is no "for their version of the software".

The latest version available is universal across all SignStream application versions...major and minor.

Currently the SignStream application doesn't know that the "latest" version if downloaded may not be readable in that version of SS.

Making SignStream look for only the "latest" version that it can "open" would alleviate the situation.

— Reply to this email directly, view it on GitHub https://github.com/DCS-LCSR/SignStream3/issues/609#issuecomment-1430067524, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADH7NQXKHXLPVIW5LQJ6SV3WXO2D7ANCNFSM6AAAAAATBGRKUY. You are receiving this because you were mentioned.

[cneidle]

Is there a reason that we need anything more than the initial check of the global Sign Bank file upon launching SignStream?

All SS has to do is check to see whether the installed Sign Bank = the latest version compatible with the SignStream version (i.e., check against the appropriate directory). If not, offer the user the opportunity to update or delete the global Sign Bank file.

Why is anything else needed?

[cneidle]

My understanding is that nothing more needs to be done at this time. But I don't think anything is needed in the future, beyond the initial Sign Bank check done upon launch, and ensuring that global and local sign banks are readable, even though there is currently no way to update the format of a local sign bank. Not sure what the consequences of this will be going forward. But done for now.

[gregorydimitriadis]

The changes here involve a checking of the local and global files separately, such that (for whatever reason) the global file is of a too new version, the local file will still parse and can be used from the MorphPhon window.

[cneidle]

great! thank you.

[gregorydimitriadis]

Released in 3.4.1