Re: [Json] Nudging the English-language vs. formalisms discussion forward

[Nico Williams <[e-mail]>]

On Wed, Feb 19, 2014 at 4:23 PM, Andrew Newton <[e-mail]> wrote:
> On Wed, Feb 19, 2014 at 12:30 PM, Tim Bray <[e-mail]> wrote:
>> I think clear English prose is *essential*, the one thing a specification
>> must have. Thus, schemas can be actively harmful if arguing over them
>> distracts attention from crafting the prose properly.  This is particularly
>> the case when the schema language is a flawed tool, which so many of them
>> are.
>
> I agree, clear English prose are essential. At the moment, I am
> evaluating two competing security protocols, both open standards
> specified with XML Schema of which one is the product of an IETF
> working group. The IETF standard is much clearer to understand because
> it offers prose on top of the XSD. I cannot help but think that the
> reason the IETF standard stands out is simply because it is an IETF
> standard; along the way to RFC it was reviewed and reviewed and people
> simply would not have let it pass had it been only an XSD. Therefore I
> do not think we need to worry about IETF specifications being harmed
> by schemas.

So you agree that prose is needed (no one here yet disagrees), but you
don't think schemas are harmful because we generally require prose
(which we do) and that's good.  Good!

We do need prose-mostly descriptions of protocols.  We need formal
languages to avoid accidents and to convey concisely and precisely
things that can be difficult to do in prose (in any natural language).
 Prose is needed for semantics -- formal alternatives for that (e.g.,
SDL) so far haven't worked well.

What I want to avoid:

 - TLS-style tool-less inconsistent ad-hoc syntaxes
 - SSHv2-style tool-less inconsistent ad-hoc syntaxes
 - 100% prose-only (e.g., SASL)

I also do not want an ASN.1 where the only way to implement is either
a) spend years building tools first, or b) ad-hoc manual coding based
off a syntax that's full of nuances (since this leads to accidents).

Whatever schema(s) we go with has to be simple enough that ad-hoc
manual coding off of the syntax is less likely to cause accidents than
ad-hoc manual coding off of prose, while also being usable with
automatic tooling.

Since we're talking about JSON we don't need to worry about silly
warts like DER/BER/CER tagging.  No need to mention such nastiness :)

Things I'd consider, and maybe propose:

 - just pattern-matching validation rules (e.g., using the jq or other
similar language that can do pattern matching);

 - a schema with describe-by-example-mostly metaschema, with special
names denoting "types" defined separately, something like:

{
    "message": { "sender": "_sender_type, "receiver":
"_receiver_type", "payload": "_json_string"}
    "sender": { ... },
    ...
}

 - a schema like compact RelaxNG that can be parsed and converted into
one of the above;

or anything else that's relatively simple and from which code can be
generated (or which can be interpreted) to at least do validation (for
testing, not necessarily at run-time in production), and preferably
more (e.g., RPC-like stubs, programming language types, ...).

Nico
--