fix: improve doc item typing

[vagenas]

No description provided.

[PeterStaar-IBM]

I think you forgot the FormItem in the ContentItem

[cau-git]

I assume the reason this works with serialization and deserialization, despite setting a level default, is becuase the label is now non-overlapping to the label literals in TextItem? If yes, that's great.

[vagenas]

Yes, label is now non-overlapping — and is actually used as the discriminator field in ContentItem further below.

[cau-git]

I am not sure we need a FormItem at this point. We can delay putting this in up until we will use it.
The changes for the layout processing in docling-project/docling#530 currently put simply a GroupItem for Forms and Key-Value-Regions, which act purely as groups without special semantics.

[mergify]

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🟢 Enforce conventional commit

Wonderful, this rule succeeded.

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?(!)?:

🟢 Require two reviewer for test updates

Wonderful, this rule succeeded.

When test data is updated, we require two reviewers

• #approved-reviews-by >= 2

[dolfim-ibm]

Can we easily enforce the type also in the add_text() method?

[vagenas]

Can we easily enforce the type also in the add_text() method?

Technically it will now be "enforced" when the TextItem is created within that method.

If you mean in terms of reflecting it to the typing of the label param: if we invest more efforts in that area, I would rather do it in a way that reuses the type validation of the various DocItems, e.g. have a single add_node(), but I see that as requiring some redesign, and in general outside the scope of this PR.

[PeterStaar-IBM]

Awesome, let's get it merged!