-
Notifications
You must be signed in to change notification settings - Fork 2
enforce agreement between existing terms and labels where ever applicable #4
Comments
@jmcmurry I'm not exactly sure what you mean here, or whether this is still relevant. We need to distinguish between two types of id/label pair:
There is a known problem now where fooLABELcan be customized and the corresponding fooID is not invalidated (working on that bug now). |
Here's my latest understanding; I defer to @cmungall for confirmation. Current need:
Medium-term need:
Eventual need (term request mechanism):
|
@jmcmurry There is currently a diversity of opinion about when and where certain types of checks, user feedback and data transformation should occur. Right now, we are favoring a 'dumb' inca-form and a (not yet written) 'smart' backend. A similar issue was discussed here regarding duplicate detection. #32 IMHO, the inca-form should be 'smart' and try to avoid users entering bad data, but we are also trying to avoid maintaining a server to handle this. So if we can't put the code in the browser, we have to either defer it (via Travis/Jenkins), or write a server. Some of our tooling can potentially be adapted to work in the browser (e.g., Scala via ScalaJS), but Python/Java code is useless in the browser. |
I'm missing something; why does it need a server? Can't browser just do a check using the existing API calls and check the label on record? |
Enforce agreement between existing terms and labels where ever applicable. Change a term it fetches the correct label. Change the label and it fetched the new term, insist on a different label and you are generating/requesting a new term.
The text was updated successfully, but these errors were encountered: