> The more I think about it, the more I like three sets of information,
> first the base path (length, sequence of identifiers)
> then one or more TLVs for the subscripts, where the TLV wil contain an
> index identifier and the data to be used as a subscript. This may be the
> base subscript, or some other field. (The identifier is a field identifier
> rather than a type identifier since there might be two key fields for the
> same table with the same type, but differing values.)
> Then for modify operations (and GET responses?) a TLV for the actual data.
> If we want to allow block references, then the structure of the subscript
> TLV can be expanded to indicate ranges somehow.
> This keeps the notions of "what structural thing", "which instance", and
> "what value" cleanly separated.
[Weiming] I understand your state as first coming the field IDs, then the
indexes, and last the values. A little worry is that in some cases, the field
IDs and the indexes have to be interfered to reference an entry, that is, the
path may be something liek fieldID.index.fieldID, When the index appear in the
path is important for correct addressing, that is, fieldID.index.fieldID is
different from fieldID.fieldID.index, therefore, to separately express fieldID
and indexes may make things more complex.
Cheers,
Weiming
