Inconsistencies in Transaction type definitions make finding and understanding the information less easy.

[FrankSzendzielarz]

The transaction reference page does not mention Asset Destroy in the TOC or as a header, nor Asset Create. However, once this transaction type is discovered, it can be found on a page with much more info .

This seems inconsistent with the way the Asset Transfer transaction type is documented as offering Asset Transfer , Accept (Opt In) and Clawback. Also Asset Accept is used as a synonym for Opt In, which is a further confusing inconsistency.

If the axfer txn type can be used for very different operations (Transfer, Opt In and Clawback), if acfg followed suit (for Create , Update and Destroy) things would be clearer.

However, going further, grouping transaction types into general area, "axfer" for anything to do with account/asset relationships and "acfg" for anything to do with CRUD on an asset type, is IMO a complication in the first place.

If each transaction type was given its own label, or sub type eg: "acfg/destroy" (or split into 2 fields) then that would make class modelling of the transactions in JSON specs, APIs, SDKs and automatic deserialisation a lot easier.

The confusion passes into the SDKs: These are currently designed as offering a general all-encompassing Transaction object with a bunch of CreatePaymentTransaction, CreateAssetDestroyTransactions, etc etc methods, which is poor OO design. A generally more helpful and easily maintained approach is to have the Transaction classes subclassed according to specific type and then allow serialisers/deserialisers/indexers etc etc switch on an explicit type (acfg/destroy). Rectifying this in the current SDKs needs work arounds to select transaction type during serialisation.

Describe the solution you'd like

1. Update the Txn Ref docs with the missing implicit transaction types.
2. Add a new field or modify the existing field so that each transaction type from Asset Destroy to Call Application is uniquely identified and have all these modeled in a proper OO way throughout the whole system.

Describe alternatives you've considered
Being eternally sad.

Additional context