API change with rowID & fieldName added to notices

[RobH123]

Of course, those are optional fields -- not present in all notices. Note that duplicate info in location is not yet fully removed (but that change should not affect the calling app code itself).

Also, moved sample notice processing from core to demos to make it clearer that the calling app is in charge of presentation (this package is NOT an RCL).

I think no more API changes planned in the near future, except possibly deprecating location completely.

[PhotoNomad0]

Some additional change requests:

In src/core/annotation-table-check.js, can we rename TABLE_TEXT_VALIDATOR_VERSION or remove it?

In book-package-check.js, can we remove the section from line 532 to 538 that does the fetchRepositoryZipFile() calls. That should likely be done in the app.

[PhotoNomad0]

Also I don't see that the version number has been changed in package.json

[mandolyte]

Some additional change requests:

In src/core/annotation-table-check.js, can we rename TABLE_TEXT_VALIDATOR_VERSION or remove it?

In book-package-check.js, can we remove the section from line 532 to 538 that does the fetchRepositoryZipFile() calls. That should likely be done in the app.

@PhotoNomad0 Not sure I understand the reasoning here. At present, the app "knows nothing" about where the data comes or how it is acquired. There is one line in the app that interacts with this package, namely:

  const rawCBPResults = await checkBookPackage(username, language_code, bookID, setResultValue, checkingOptions);

Why should it "know" more?

Here is the change in the PR:

For the app to do this, it will have to updated to use the gitApi -- I would probably just copy the folder in the package over to the app. Then I guess I'd have to precede the current single line above with this loop. So then the app would have the following features it doesn't now have or need:

• It would now know about book package resources
• It would now know how to interact with DCS

At present it only knows about the data structure returned by the CV package. I'd rather keep it that way!

[PhotoNomad0]

In testing, I found that fieldName is missing from location field in error messages. It seems that it should be added back in here. Otherwise you get a message like Unexpected doubled . characters, but still have to go looking through all the fields of the tsv to find it.

[RobH123]

No @PhotoNomad0, it doesn't need to be added back into the location field of the notices, but if it's missing from the error messages, then I must have missed passing through the rowID field somewhere and need to find where that is. (If you can tell me the priority number of a sample notice where rowID is missing, that helps me to narrow down the code.) Oh, I see your code fragment above -- maybe you've already tracked it down!

[RobH123]

I think we need to accept this PR so we can progress, since it was a fairly large refactoring. I will still be working on improving those and other notices, but those small fixes hopefully will no longer change the API.

[RobH123]

Not sure I understand the reasoning here. At present, the app "knows nothing" about where the data comes or how it is acquired.
...

At present it only knows about the data structure returned by the CV package. I'd rather keep it that way!

I think you've solved it already @mandolyte, but yes, I think that the calling app has to do preloading of repos, Otherwise they would be loaded again for each book, and maybe even loaded near simultaneously which could cause overwrite issues.