1 |
=head1 REGISTRATION INFORMATION |
2 |
|
3 |
Tag 27 |
4 |
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 |
27(["ISO/8601", "2013-11-16"]) |
33 |
27(["AmountDue", 100, "EUR"]) |
34 |
27(["C/wchar_t", 71626272]) |
35 |
|