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_list | Sequence of elements |
| | "" | ||
element | ::= | "\x01" e_name double | Floating point |
| | "\x02" e_name string | UTF-8 string | |
| | "\x03" e_name document | Embedded document | |
| | "\x04" e_name document | Array | |
| | "\x05" e_name binary | Binary data | |
| | "\x06" e_name | Undefined — Deprecated | |
| | "\x07" e_name (byte*12) | ObjectId | |
| | "\x08" e_name "\x00" | Boolean "false" | |
| | "\x08" e_name "\x01" | Boolean "true" | |
| | "\x09" e_name int64 | UTC datetime | |
| | "\x0A" e_name | Null value | |
| | "\x10" e_name int32 | 32-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:
Post a Comment