Discussion on Path

Weiming Wang

<wmwang@mail.hzic.edu.cn>

IETF 61th Meeting, Washington, Nov.7-12, 2004

Data Structure for LFB Attributes (1)

AttrID2AttrID1 AttrIDx

i f1 | f2 | …. f1 | f2 | ….

g1 | g2 | ….g1 | g2 | …. j

Value=vf1

Value=vg1Value=vg2 LFB

Value=v1 …

Data Structure for LFB Attributes (2)

– (LFB attributes here include attributes, events, capabilities)

– An LFB contains attributes identified by Attribute IDs

• LFB Attributes = { AttrID1, AttrID2, … }– Attribute IDs are defined by XML (Static)

– An Attribute may be composed of no or several fields (c

ompound), e.g.(in the figure), • AttrID1={}, AttrID2={f1, f2, … },

Where, AttrID1 has no field (actually means only one field therefore do not need to ID it, while AttrID2 has fields f1, f2…

• Every field has a fieldID, which is also defined by XML(static)

Data Structure for LFB Attributes (3)

– An attribute may be atomic or a table, e.g. (in the figure), • Atomic: AttrID1• Table: AttrID2[i]where ‘i’ is called index or subscript for a table (dynamic)

– A field can be recursive in the data structure, e.g.(in the figure),

• f2 in AttrID2 above may be another table with compound subfields as:

f2[j]={g1, g2, …} where, j is index for the table, g1, g2 … are subfields (static).

– Terminal fields (not recursive anymore) then have values, e.g. (as in the figure),

• AttrID1=v1• AttrID2[i=1].f1=vf1• AttrID2[i=1].f2[j=1].g1=vg1, AttrID2[i=1].f2[j=1].g2=vg2

Data Structure for LFB Attributes (4)

• Summary– Attribute ID and Field ID plays important roles

for Data structure of LFB attributes– Field ID and index(subscript) are two totally

different notions

Path – Index based• Use index i, j e.g.,

– Get i=10 in table of AttrID2 • Path = AttrID2[i=10]

– Get j=20 in table f2 of table AttrID2• Path = AttrID2[I=10]. f2[j=20]

• Comments– Simple in expression and fast for searching– Should use Attribute ID and field ID (f2) as well as

index i,j.– Not valid for items that do not have index, like atomic

item, and events, capabilities that do not originally have index

– Not always necessary for small size tables

Path- field ID based• Use field IDs only, e.g.,

– Get value of AttrID1• Path = AttrID1

– Get items of AttrID2 which meet the conditions as f1= vf1 and g1=vg1

• Path = {AttrID1.f1= = vf1} && {AttrID1.f1.g1 = = vg1}

• Comments– Do not need to manage index– Fit for attributes with atomic or small size table data

types, and for capabilities and events that do not originally have index.

– Is content based searching, lower the efficiency for large scale tables

Path• Conclusion

– Index based and field ID (content) based addressing are all necessary

– The Attribute ID part is always needed for both ways, therefore can be pulled out, as

– Path := AttributeID <Index or Field Ids>+

• Suggestion– The followed <Index or field Ids> part be included in the

Data field rather than in the PL layer for the protocol to define the complex structure like

[I=10]. f2[j=20] {AttrID1.f1= = vf1} && {AttrID1.f1.g1 = = vg1}

The End