More notes
This commit is contained in:
parent
9cb8ef45c9
commit
cf250b9245
11
preserves.md
11
preserves.md
|
@ -1384,7 +1384,10 @@ what? Some domain-specific base URI?
|
|||
|
||||
Q. Literal small integers: are they pulling their weight? They're not
|
||||
absolutely necessary. They mess up the connection between
|
||||
value-ordering and repr-ordering!
|
||||
value-type-ordering and repr-tag-ordering! (The connection between
|
||||
*value* ordering and *repr* ordering is already irretrievably messed
|
||||
up: length prefixes blow lexicographic ordering away, sign bits are
|
||||
the wrong way around, floats are sign-magnitude, etc etc.)
|
||||
|
||||
Q. Should we go for trying to make the data ordering line up with the
|
||||
encoding ordering? We'd have to only use streaming forms, and avoid
|
||||
|
@ -1416,4 +1419,10 @@ should it be changed to case-sensitive?
|
|||
|
||||
TODO: Examples of the ordering. `"bzz" < "c" < "caa"`; `#true < 3 < "3" < |3|`
|
||||
|
||||
TODO: Probably should add a canonicalized subset. Consider adding
|
||||
explicit "I promise this is canonical" marker, like a BOM, which
|
||||
identifies a binary value as (first) binary and (second, optionally)
|
||||
as canonical. UTF-8 disallows byte `0xFF` from appearing anywhere in a
|
||||
text; this might be a good candidate for a marker sequence.
|
||||
|
||||
## Notes
|
||||
|
|
Loading…
Reference in New Issue