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 |
|