It would be nice if everyone wrote points that he/she thinks are important to consider to make a decision.

Points to consider:

• Request structure is strict and can be easily converted to class/struct in statically typed programming languages
• JSON Request (if any is present) structure can be described with json-schema (for better documentation and easier validation)
• IDs of forms and senses are auto-incremented. ID counters exist per lexeme: one for forms, one for senses
• Conflict resolution if two persons try to create form/sense in the same time
• User should not be able to create form/sense with ID that he/she provided
• Form/Sense class should not reference Lexeme in any way (neither on object level, nor having LexemeId as a part of it's ID). I can see how this can improve maintainability
• Form ID should always be unique, even if the Lexeme was reverted new form should get an ID that was never used before

Form/Sense class should not reference Lexeme in any way (neither on object level, nor having LexemeId as a part of it's ID). I can see how this can improve maintainability

I strongly disagree. Forms and Senses must have the Lexeme ID as part of their ID. That's actually part of the data model specification.

Some points from my side:

• Clients should be able to re-use code for creating different kinds of entities
• Forms and Senses should be treated just like other entities, for consistency
• All APIs that create or edit entities must consistently apply the appropriate checks for permissions, tokens, etc.

... That's actually part of the data model specification.

As I understood it is not set in stone, or is it?

In T172192#3493920, @Aleksey_WMDE wrote:

... That's actually part of the data model specification.

As I understood it is not set in stone, or is it?

It was discussed over and over, and has become part of a spec. Nothing is using the spec yet, but we'd have to have a very good reason to open that discussion again. I currently see no reason for that.

Note that there technically is no need for FormId or SenseId to know about the LexemeId class, or about the syntax of Lexeme IDs. If we don't need the code to be restrictive about this, it can just know that there is a parent Entity ID. It doesn't need to care about the type of syntax of that parent entity ID.

We also can have this knowledge in only in the presentation layer (HTML/API), but not in the object model and serialization.

We also can have this knowledge in only in the presentation layer (HTML/API), but not in the object model and serialization.

Without considering all factors having a FormId not know what Lexeme it is related (or maybe not even know it is a part of some other entity?) seems an appealing option.
While it would clearly need changing some places of the code (i.e. you probably don't want to allow Form entity to be written to DB on its own) but it seems it could simplify at least some of steps listed in T165328.

I guess it is difficult to say (at least for me) which of approach would be "easier" in end without having at least some code at hand but at glance it seems to me that not adding a notion of hierarchical entity IDs to the data model and have most of logic in the actual code using data model might be cleaner and simpler.

Change 374524 had a related patch set uploaded (by WMDE-leszek; owner: WMDE-leszek):
[mediawiki/extensions/Wikibase@master] [DNM][POC] Demonstrate how possibly API class could allow handling "hierarchical entity IDs".

https://gerrit.wikimedia.org/r/374524

Create those using wbeditentity

+1 as said previously.

Clients should be able to re-use code for creating different kinds of entities
Forms and Senses should be treated just like other entities, for consistency
All APIs that create or edit entities must consistently apply the appropriate checks for permissions, tokens, etc.

Also +1 to all of this from daniel

I may have other comments once reading discussions in other places.

Change 374524 abandoned by WMDE-leszek:
[DNM][POC] Demonstrate how possibly API class could allow handling "hierarchical entity IDs".

https://gerrit.wikimedia.org/r/374524

There's been no update here since a year. Here is what's there now, to have an overview:

One can create form/sense using wbeditentity, either by:

• new=form/new=sense and data containing lexemeId=L123, or
• id=123 and data containing element in forms or senses that has the add key instead of id.

There are also dedicated APIs end points, respectively wbladdform, and wbladdsense, for adding single form/sense to a lexeme.
These endpoints are currently used by lexeme page UI.

The lexeme modification "logic" used by both API endpoints is shared, thus it should be possible to stop using one approach with only keeping the other.

wbladdform/wbladdsense APIs generate "meaningful" edit summaries, whereas wbeditentity always yields "Edited lexeme L123", due to limitations in wbeditentity itself.

If it was e.g. intended to phase out wbleaddform/wbladdsense APIs in favour of wbeditentity, the only change that could be consider potentially critical/important. would be the change to edit summaries.