Re: [Forces-protocol] Feedback: Section 6.4

[Jamal Hadi Salim <[e-mail]>]

On Sun, 2004-10-24 at 23:44, Wang,Weiming wrote:
> ----- Original Message -----
> From: "Jamal Hadi Salim" <[e-mail]>
> 

> > So while you are defining that at the top; i think its also important to
> > have a subsection somewhere which says something along the lines of:
> >
> > ---
> > Every attribute within an LFB will have a unique 32 bit ID defined
> > during the LFB definition. This allows mapping any attribute within an
> > LFB to a path not unlike the SNMP OID.
> >
> > Below is an illustration of a complex example and how the different
> > attributes could be accessed.
> >
> > Assume LFB Class A.
> > It contains two Arrays, B, and C (assigned identifiers 1 and 2)
> > A also contains a structure of type Stoo with a human name F.
> > F is assigned ID 3.
> > A also contains two attributes, D and E assigned identifiers 4 and 5.
>
> [Weiming]I suppose the attribute identifier (4, 5) will be assigned by XML as
> you mentioned (I see some necessity to be defined by IANA). Definitely, user
> will not be able to define the ID, or there will be no operabitlity.
> 

Right. As an example in noop.xml i posted earlier, foo1 has ID of 3
and foo2 has ID of 4. Thats defined when noop.xml was defined.

> > Array B is an array, indexed as a table, whose contents are int32s.
> > Array C is an array, indexed as a table, whose contents are a structure
> > named Star.
> > Stoo type structures contain elements X and Y, each characters,
> > assigned identifiers 1 and 2.
> > Star contains An element N (a sting), assigned identifier 1, and an
> > array
> > Arr, assigned identifier 2, indexed as a table, containing int32s.
> >
> > To reference entities within an LFB instance of Class A, selectors
> > are as follows:
> >
> > 1, meaning the full array B
> > 3, meaning the full structure named F.
> > 2, 7 meaning the full structure in the seventh entry of the array C.
> > 4 means the attribute D
> > 2, 8, 2, 9 meaning the 9th number in the array in the structure in the
> > eigth slot of the array C.
> > Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct
> > type definition.
> > -------
>
> [Weiming]Followed by above comments, a very simple question is how will you
> address the D and E attributes as you mentioned as two different attributes? I
> see it's possible only if you save a section inside the 32bit 'path'
> specifically for attribute type ID. That means this section are not allowed
> freely used by users. Because of this, i then prefer to have a specific field
> (AttributeTypeID, which I refered as attribute ID) for it. Note that I'm not
> saying 'path' is useless, I just think it can be followed in Data field.
> 

Lets take an example of noop, since the xml for that is there and its a
very simple example.

The class NOOP is 5. owned by IANA.
It has a simple table called datatable whose ID is 6. Defined at xml
creation.
To point to first entry of datatable: 6,1
to point to foo1 within entry 2 of datatable: 6,2,3
to point to foo2 of entry 3 of datatable: 6,3,4

I hope this clears it. I have attached two docs i worked on to 
clarify this.

As i said earlier, the path issue is resolved but not the data packing.
Of course if you disagree we could continue that discussion.
As you will notice in these docs, the text clearly states that the 
data packing is not resolved.

cheers,
jamal

_______________________________________________
Forces-protocol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol