High level Design (and considerations) for (batch-like/mass retrieval) Attribute interface (for direct access without using classes)

[J007X]

Is your feature request related to a problem? Please describe. As discussed in meetings, for (batch-like/mass retrieval) Attribute interface (for direct access without using classes) we need a high level design (and considerations) ticket to organize (and provide summary) for those sub tasks will be generated from the designs/considerations listed in this ticket.

Describe the solution you'd like The attribute interface (for batch-like/mass retrieval) extends the capability for access attributes "as range/batch" for one or more tid(s), or specific type, so that the methods can be used for higher level classes for quick, data-class-less access for the range of attributes (such as in pipeline processors). Current implemented methods are:

• [x] Using specified list of attribute names, and tid(s) or type name for batch access (as in PR921, phase 1 lower level interface at data_store level).

Describe alternatives you've considered Alternatively (or additionally), there can be other combinations for input/request: such as

• [ ] (Optional) Access using attribute index (list of number, or range)], or Using list of attr_id (if user know them) for selecting attributes,
• [x] return format (for attributes) can be dict for easy access using attribute name (as in PR921)
• [ ] Also, write-access is very likely be needed in additional for read-access to further boost performance (in batch mode)

Additional context For type based selection of entries, should consider keeping simple "one type at a time" style for accessing the attributes (same as "get" in the data_store), as it seems little (if any) benefits can be gained by mixing several type's attributes (needs to be common) together in one return.