Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward)

[Nico Williams <[e-mail]>]

On Thu, Feb 20, 2014 at 10:55 AM, Pete Cordell <[e-mail]> wrote:
> My position is that, having recognised that Dates represent a case where
> microformats are useful, perhaps we should not assume that these are the
> only cases.  IP addresses?  Crypto OIDs?  Dates on Mars?

There are two ways to deal with alternative representations:

 - convert to/from a canonical representation and use that one for interchange
 - use a discriminated union (XDR) / CHOICE (ASN.1, same thing)

I think any decent schema will need to allow for the latter, and not
just because of types that have multiple possible representations.

As for the former, it's always an option, schema or not.  And it's
more efficient to have receiver-makes-right in this case (dates &
timestamps), though that does require having a fixed set of
representations that can be sent, else a negotiation would be
required.

This seems obvious enough that we shouldn't dwell on it.

The real question is: which schema(s) should we be copying/learning
from?  So far the answer seems to be down to:

 - Schematron
 - RelaxNG compact
 - Web IDL

I think that's a fine starting point.

If you want to talk about requirements, I think we should consider things like:

 - which grammar parsing algorithms we want to support: LR, LALR(1),
LALR(k), GLR, ...

 - the basic metaphor:
    - types! (a-la ASN.1, only without the tags, no IOS, ...)
    - pattern matching rules! (something like collections of
XPath-like expressions)
    - something else

The metaphor thing gets to, in part, the purpose of the schema:

 - documentation for sure, validation no doubt, but, code generation
(into C, Java, JS, C#, ...)?  (IMO: yes)

Finally:

 - extensibility (meta: to have it or not; if yes, how)

 - modularity (meta: to have it or not; if yes, how)

Oh, and:

 - one schema language, or more?  (IMO: inevitably we'll end up with more)

I may have missed some things.  But I think that's a decent set of
attributes from which to start a schema requirements discussion.

Nico
--