(src-js) `ApiRelationshipType` is missing `TABLE_TITLE`

[rob3c]

It's unclear whether this library is intentionally restricting the types exposed by the Textract API responses or not, but the typescript types have a number of omissions that prevent us from accessing certain properties and values without coding around them (e.g. my previous issue about the missing Page property on blocks.)

In this case, ApiRelationshipType is missing TABLE_TITLE, which can even be seen in the JSON test responses used in this project's test suite.

The types in this library are often more useful than those in @aws-sdk/client-textract. For example, they're not all declared with optional properties when the API always includes certain values, properties are omitted entirely depending on BlockType, etc.

Since Textract is often confused and doesn't parse e.g. tables correctly for certain layouts, I need to write custom code to find the missing data elsewhere in the results to fix things. I'd like to use the types in this library with that code whenever possible for simplicity.

However, if the types here only represent the subset of the Textract API model surface area that is used internally by this library, then I won't bother the maintainers with more issues like this. Just let me know.

Thanks in advance!

[athewsey]

Hi @rob3c - thanks for your feedback on the library and calling this issue out!

Previously, TRP.js was not properly pulling through links from tables to TABLE_FOOTER and TABLE_TITLE blocks... So this was definitely a bug.

I believe it should be fixed in the pre-release 0.4.0-alpha.3 now available on NPM - if there's any chance you'd have time to test it out?

---

To your question about feedback like this in general:

• Yes, it's definitely appreciated! Often our custom type model has been built using real-world observations rather than theoretical guarantees (since those are often over-vague, like in @aws-sdk/client-textract), so it's useful to hear if folks see any discrepancies
• ...But of course I guess it's possible there'd be cases where fixing the API type model could introduce conflicts with the actual library that'd take a lot of effort to fix - in which case would probably appreciate your patience that a fix might be slow 🥲

[athewsey]

amazon-textract-response-parser v0.4.0 is now released and we believe should address this issue (and generally fix/implement TABLE_TITLE & TABLE_FOOTER blocks properly).

Thanks for the feedback, and please do re-open if you're still seeing the original problem!