| 1 |
root |
1.1 |
=head1 REGISTRATION INFORMATION |
| 2 |
|
|
|
| 3 |
root |
1.2 |
Tag 27 |
| 4 |
root |
1.1 |
Data Item array [typename, constructargs...] |
| 5 |
|
|
Semantics Serialised language-independent object with type name and constructor arguments |
| 6 |
|
|
Reference http://cbor.schmorp.de/generic-object |
| 7 |
|
|
Contact Marc A. Lehmann <cbor@schmorp.de> |
| 8 |
|
|
|
| 9 |
|
|
=head1 DESCRIPTION |
| 10 |
|
|
|
| 11 |
|
|
The generic-object tag in CBOR can be used to serialise complex objects |
| 12 |
|
|
in CBOR. It is meant to exchange complex datatypes that are not tied |
| 13 |
|
|
to a specific language or implementation, between CBOR implementations |
| 14 |
|
|
that use different internal representations. It is quite similar to |
| 15 |
|
|
CBOR tags themselves, the main difference being that the tag namespace |
| 16 |
|
|
is not numeric but a string, providing easier extensibility than CBOR |
| 17 |
|
|
tags, making automatic type mapping to CBOR possible and improving the |
| 18 |
|
|
self-documenting nature of these objects. |
| 19 |
|
|
|
| 20 |
|
|
There are no rules that specify how to serialise or deserialise objects |
| 21 |
|
|
using this tag - sender and receiver need to agree on how to handle these |
| 22 |
|
|
tags when they want to understand their semantics. Receivers can always |
| 23 |
|
|
opt to handle them like any other unknown tag. |
| 24 |
|
|
|
| 25 |
|
|
The typename is usually a class name, or another string that indicates |
| 26 |
|
|
the name of the type. It is suggested, but not required, to prefix |
| 27 |
|
|
the typename with a language name or other identifiying string, and a |
| 28 |
|
|
slash. Additional array members are determined by the data type. |
| 29 |
|
|
|
| 30 |
|
|
=head1 EXAMPLES |
| 31 |
|
|
|
| 32 |
root |
1.2 |
27(["ISO/8601", "2013-11-16"]) |
| 33 |
|
|
27(["AmountDue", 100, "EUR"]) |
| 34 |
|
|
27(["C/wchar_t", 71626272]) |
| 35 |
root |
1.1 |
|
