… | |
… | |
187 | The semantics of stringref tags require the decoder to be aware and the |
187 | The semantics of stringref tags require the decoder to be aware and the |
188 | encoder to be under control of the sequence in which data items are |
188 | encoder to be under control of the sequence in which data items are |
189 | encoded into the CBOR stream. This means these tags cannot be implemented |
189 | encoded into the CBOR stream. This means these tags cannot be implemented |
190 | on top of every generic CBOR encoder/decoder (which might reorder entries |
190 | on top of every generic CBOR encoder/decoder (which might reorder entries |
191 | in a map); they typically need to be integrated into their works. |
191 | in a map); they typically need to be integrated into their works. |
|
|
192 | |
|
|
193 | =head2 DESIGN RATIONALE |
|
|
194 | |
|
|
195 | The stringref tag was chosen to be short, without requiring standards |
|
|
196 | action. The namespace tag is rare, so doesn't benefit from a short |
|
|
197 | encoding as much. |
|
|
198 | |
|
|
199 | Implicit tagging/counting was chosen to support stream encoders. Having |
|
|
200 | to tag strings first requires either multiple passes over the data (which |
|
|
201 | might not be available, ruling out some encoders) or tagging more strings |
|
|
202 | than needed (wasting space). Explicit tagging also isn't necessarily |
|
|
203 | better even under optimal conditions, as the explicit tags waste space. |
|
|
204 | |
|
|
205 | Stream decoders are affected less by implicit tagging than encoders. |
|
|
206 | |
|
|
207 | The namespace tag was introduced for two reasons: first to allow embedding |
|
|
208 | of CBOR strings into other CBOR strings, secondly for decoding efficiency |
|
|
209 | - the decoder only has to expect stringref tags inside namespaces and |
|
|
210 | therefore doesn't have to maintain extra state outside of them. |
192 | |
211 | |
193 | =head1 EXAMPLES |
212 | =head1 EXAMPLES |
194 | |
213 | |
195 | The array-of-maps from the rationale example would normally compress to a |
214 | The array-of-maps from the rationale example would normally compress to a |
196 | CBOR text of 83 bytes. Using this extension where possible, this reduces |
215 | CBOR text of 83 bytes. Using this extension where possible, this reduces |