Saturday, December 17, 2011

Bjson structure

Basic Binary json types:

byte 1 byte (8-bits)
int32 4 bytes (32-bit signed integer)
int64 8 bytes (64-bit signed integer)
double 8 bytes (64-bit IEEE 754 floating point)

My terminology says these are descriptions of our keyword should be interpreted when doing bjson operations. Then they have an enclosure format:


document::=int32 e_list "\x00"BSON Document
e_list::=element e_listSequence of elements
|""
element::="\x01" e_name doubleFloating point
|"\x02" e_name stringUTF-8 string
|"\x03" e_name documentEmbedded document
|"\x04" e_name documentArray
|"\x05" e_name binaryBinary data
|"\x06" e_nameUndefined — Deprecated
|"\x07" e_name (byte*12)ObjectId
|"\x08" e_name "\x00"Boolean "false"
|"\x08" e_name "\x01"Boolean "true"
|"\x09" e_name int64UTC datetime
|"\x0A" e_nameNull value



|"\x10" e_name int3232-bit Integer


If you pick through it one sees a good idea with recursive definition, compact form, binary format, this can be made faster. How? lets get fixed fields on the datatype type, get that field on the link field. Let the machine handle length value for key word. In TE this, well my version of TE, is: string$MyName These are also the definitions in schema and pre-formatted forms, right? The need about 30 slots in the link field, hey, make bjson triplet format. Use it as the basis for overloads on key word and for schema matching or form fill in or schema enforcement. Better than Dublin core.

No comments: