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

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Feb 20, 2014 at 12:22 PM, Nico Williams <[e-mail]>wrote:

> 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.
>

In the code as it is right now it is possible to specify different formats
as different tags:

ConvolutedTime Structure
    DateTime                Date
    Format RFC1123     Date1
    Format RFC822       Date2

Would allow for any of the following:
    {"Date":"2002-10-02T10:00:00Z"}
    {"Date1":"Thursday, 20 Feb 2014 18:14:16 GMT"}
    {"Date2":"Thu, 20 Feb 2014 18:14:16 GMT"}

What I don't support at the moment is a constraint that says that only one
of the "Date", "Date1" and "Date2" tags is permitted. This could be
specified as:

ConvolutedTime Choice
    DateTime                Date
    Format RFC1123     Date1
    Format RFC822       Date2

[Protogen does allow braces to be used instead of indentation to denote
blocks but does not need end of statement or statement separators. If
people really insist on semicolons I can add a production to the lexer so
they are just treated like whitespace.]

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

I would hope we make the syntax so simple that we don't need the power of
LR parsers. They are models of human languages rather than computer
languages.



>  - 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
>

Since the target languages are likely to be C#, JS and Java, I suggest that
we use dot separated tags and array indexes as path extractors.

Given:

{"first" : {"second" : {"third" : [{ "fourth": 1}, { "fourth": 42}, {
"fourth": 666}]}}}

first.second.third[1].fourth = 42



> 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)
>

I have code generation for C# and C. I can add Java without difficulty.

It is not clear to me that code generation is necessary or particularly
useful for scripting languages with late binding like JS. In those
situations you can just say

X = JSON_Parse (text)

Answer = first.second.third[1].fourth



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

Hopefully formats are enough.


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

I am adding a Using directive right now. It seems to do the trick.



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

There will be multiple schemas. I think the progression will work like it
did for JSON itself. People will choose the one they like and there will
eventually be a convergence.

-- 
Website: http://hallambaker.com/