Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]

On Fri, 2004-11-12 at 23:21, Joel M. Halpern wrote:
> Sorry, I missed something.
> I believe that the protocol will have to define the encoding for all data, 
> in such a fashion that any data types (including structures) describable in 
> the model can be represented in well defined ways.

Would you say that an ID is a coherent description of a data type at
a given hierachy level? I.e as someone who knows the schema/template for
a LFB I should be able to tell with 100% certainty how to decode data if
you gave me the hierachy level and the ID (assuming the ID exists in the
template), No?

> Given such a definition, and given that the CE and FE both know the 
> definition of the data, then it can be processed.
> 
> There are actually cases where the CE may not understand part of the data 
> that he is being handed.  If the structure being returned is actually a 
> subclass, with additional fields, of that understood by the CE.  However, 
> this actually works:
> 1) The CE will be able to parse all the fields he understands
> 2) The CE will have to ignore any fields he can not understand.  Note that 
> he has to ignore them if they have no type / field ID tagging or if it has 
> type and field ID tagging, since he has no idea what those fields mean anyway.
> 

nod.

> The one implication of this is that the encoding for structures and arrays 
> must ALWAYS have a length.
> 
> As far as I can tell, tables, or tables within tables, do not change this 
> with regard to field identification.  With regard to subscripts, there is 
> room to discuss.
> 

I think every time you start encoding you need a lenght and some path ID
which says "btw, here starts foo1 which is of  length X"..
And within foo1 anytime you have anything thats of variable size such as
a string or array or cells that may reference variable sized entities
then you need again those two things { ID, length} 
If you assume these rules then you can pack data effeciently.
Sorry for jumping into encoding - it just seems that effective encoding
requires some deviation from the clean series-of-IDs approach.

> 
> Given a field foo in the LFB which has ID 2, and is a structure with fields 
> bar (id 1), bas (id 2), and bat (id 3), where bas is a structure with field 
> cab (id 1), cac (id 2) and cad (id 3), then:
> if I want to reference cac I need the path 2.2.2 somewhere.
> if I want to reference bas, I need the path 2.2 somewhere, and I do not 
> need the id 2 of cac inside the representation of bas.
> if I want the whole field foo, I need the path 2, and I do not need the ids 
> for any of the contained fields.
> 

nod

I am gonna delete the rest of the discussion on content stuff. Can we
get some agreement on this basic stuff first?

Note - I still see the queries and deleted using the series of 32 bit
IDs to create a path.

cheers,
jamal

_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol