Rationale note about annotation binary syntax
This commit is contained in:
parent
5d0bf91d30
commit
202d92d237
|
@ -140,11 +140,26 @@ represent the denoted object, prefixed with `[0x86]`.
|
|||
|
||||
«@W V» = [0x85] ++ «W» «V»
|
||||
|
||||
Each annotation `W` precedes the `Value` `V` it annotates; both `W` and
|
||||
`V` *MAY* themselves be further annotated. Implementations *SHOULD*
|
||||
default to omitting annotations from `Repr`s. See [examples in the
|
||||
Each annotation `W` precedes the `Value` `V` it
|
||||
annotates.[^annotation-syntax-rationale] Both `W` and `V` *MAY*
|
||||
themselves be further annotated. Implementations *SHOULD* default to
|
||||
omitting annotations from `Repr`s. See [examples in the
|
||||
appendix](#annotation-examples).
|
||||
|
||||
[^annotation-syntax-rationale]: **Rationale.** The syntax for
|
||||
annotated values is unlike any other compound syntax defined here.
|
||||
It allows parsers to *statelessly* skip annotations: while `0x85` is
|
||||
the next input byte, skip it, skip a single `Repr`, and then try
|
||||
again; otherwise, parse the input stream as usual.
|
||||
|
||||
By contrast, one might imagine using a parenthesized syntax like the syntax of
|
||||
compound data. In that case, parsers would have to remember
|
||||
information about nesting of annotations. This would not necessarily
|
||||
be an issue for recursive ("DOM"-like) parsers, but streaming
|
||||
("SAX"-like) parsers would have to either take on complexity
|
||||
internally or force it on their clients, even when those clients did
|
||||
not care about annotations.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
**Annotations.** In modes where a `Value` is being read while
|
||||
|
|
Loading…
Reference in New Issue