| daniel updated the task description. (Show Details) |
CHANGES TO TASK DESCRIPTION
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.
...
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? What exactly should the specialized API look like?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.
TASK DETAIL
EMAIL PREFERENCES
To: daniel
Cc: Lydia_Pintscher, Aklapper, Liuxinyu970226, Jan_Dittrich, Jonas, Addshore, daniel, Cinemantique, GoranSMilovanovic, QZanden, Wikidata-bugs, aude, Darkdadaah, Mbch331
Cc: Lydia_Pintscher, Aklapper, Liuxinyu970226, Jan_Dittrich, Jonas, Addshore, daniel, Cinemantique, GoranSMilovanovic, QZanden, Wikidata-bugs, aude, Darkdadaah, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
