Subject: Another aspect of nested path-data

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Feb 2005 07:04:50 -0500

I realized after my last note that there was another use we were making of 
nested path-data.  This use does not strictly require nesting more than one 
path-data per level, but would be awkward to handle without any nesting.

We are using nesting to flexibly support content keying on tables.
To avoid ambiguity in when a table reference has a subscript, while still 
keeping the references in order (and allowing subscripting in the actual 
path) we ave specified that content keying (KEY TLVs) is always associated 
with the end of the path of the path-data.  (For robustness we have also 
used a flag to indicate that such is being used.)

For this to be workable, so that one can do content keying and still select 
fields (or even inner array elements) past where the content key is used, 
we use nested path-data.  Using this with multiple path-data at the next 
level allows the content key (which contributes noticeably to the number of 
bytes in the path) to be shared by all of the directly nested path-data TLVs.

Yours,
Joel