ion-rfc-01-introduction.nroff

.tm 1. Introduction ................................................... \n%
.ti 0
1. Introduction

The Amazon Ion specification has three parts:

.in 9
.ti 6
o A set of data types

.ti 6
o A textual notation for values of those types

.ti 6
o A binary notation for values of those types

.in 3
All three views are semantically isomorphic, meaning they can represent
exactly the same data structures, and an Ion processor can transcode
between the formats without loss of data. This allows applications to
optimize different areas for different uses - say, using text for human
readability and binary for compact persistence - by transcribing
between the formats with almost complete fidelity. ("Almost" because
converting from text to binary does not preserve whitespace
and comments.)

The Ion text encoding is intended to be easy to read and write. It may
be more suitable for streaming applications since sequences don't need
to be length-prefixed. Whitespace is insignificant and is only required
where necessary to separate tokens. C-style comments (either block or
inline) are treated as whitespace, and are not part of the
binary encoding.

The binary encoding is much more compact and efficient. An important
feature is that parts of the whole can be accessed without
"preparation", meaning you don't have to load it into another form
before accessing the values.

.tm _   1.1 Conventions Used in This Document  ........................ \n%
.ti 0
1.1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

The grammatical rules in this document are to be interpreted as
described in [RFC5234].