We need an API input that allows Form descriptions to be edited.
We need this to be possible via wbeditentity eventually. This is blocked on T165328.
Open question: should we also have a specialized API for this? Does the specialized API come first? Would a specialized API be simpler/faster to implement than the wbeditenty one? Should the specialized API be considered internal/unstable?
Considerations for a dedicated API module for editing a Form's "head" (that is, representations and grammatical features):
- Allow representations and grammatical features to be edited together, in a single edit.
- Interface should be consistent with the wbaddform module
- The implementation should be a thin wrapper around functionality shared with wbeditentity.
- Generate useful edit summaries for all cases (change representations, change grammatical features, change both). Question: do we need separate add/remove/update operations, so we can generate better summaries?
- Define ChangeOps for representations and for gram. features, to ensure consistent behavior with wbeditentity. Define ChangeOpDeserializer for decoding JSON representation of edits.
- If we want to treat the dedicated api module as unstable/internal, we have to offer the same functionality via wbeditentity first (or at least, very very soon).
- Ensure permission checks (and token checks, but that's done by the API framework anyway)
- Ensure proper edit conflict detection/resolution
- Re-usable logic for loading and storing a Form inside a Lexeme. Doing this transparently in EntityStore/Entity(Revision)Lookup would allow this logic to be re-used outside the API, e.g. in EntityDataRequestHandler.