editorialize serialization section

[LPardue]

• Judicious editorial change to section 6
• move truncation section below json-seq
• Split optimization to guidelines and survey/speculation
• move conversion considerations to appendix
• fixup: promote truncation a level

[LPardue]

To add more colour to this PR, section 6 is very large and ranges between discussing things we really want implementers to consider - like mapping to JSON or JSON-SEQ, to other information that verges on research results or speculation. optimizations. It then oddly appears to say we aren't defining these optimizations formally but that there's normative language for how their file extensions and media types are to be handled. This sort of mixed messaging is likely to come up in wider review.

So this PR is a strawman for breaking apart the section to focus on what implementers need to do in the main body. It punts the more subjective stuff to the appendix while also watering down our guidance about how they would treat extensions or media types.

One could make the argument that compression of JSON and JSON-SEQ is mature enough an optimization to make it into the main body. I could agree with that but wanted to start somewhere.

[rmarx]

Generally, this is in good shape. The now-appendices need some editorial love to align with the (intended) tone of the rest of the text, but that might be done in another PR later.

[rmarx]

Also needs a pass to reduce line length/add wrapping at a few locations, but other than that and the nits I had, this look good to go.

[rmarx]

Not sure I'm the biggest fan of referring explicitly to the other 2 docs here, since this MAIN doc is supposed to be generic (except maybe for some examples).

[LPardue]

Right but it's too wooly to say "other related schema" - all extensions of qlog are related to the main schema. So the question becomes are we levying recommendations on additional schema to be generic, or can they make optimization for serialization formats? The latter seems reasonable to me, it's part of tradeoff that we mention in this spec.

We have two examples that are generic but don't think we can extapolate from that. This might lean towards having a serialization section in each of the documents so that they state if they are generic or specific. I created #357 to track that.