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

["Pete Cordell" <[e-mail]>]

----- Original Message From: "Phillip Hallam-Baker" <[e-mail]>
> On Thu, Feb 20, 2014 at 10:22 AM, Pete Cordell 
> <[e-mail]>wrote:
>
>> ----- Original Message From: "Phillip Hallam-Baker"
>>
>>
>>  IETF has not decided how to make JSON protocols composable.
>>>
>>
>> Isn't that why we're here?
>
>
> It is why the group is here. But my point is that the group should decide
> how to compose protocols and the people developing schemas should support
> those tropes that are chosen.
>
> So it is a separate problem. If people decide on how to do this, I will be
> happy to extend my tool. But I don't think how this problem is solved
> should be a way to decide between tools.

As it's framed at the moment, nobody has to decide between tools (at least 
not in the JSON working group).

> Yes, QNames are broken, so don't do that.  Think more packages in Java,
>> namespaces in C#.  As simple as doing something like:
>>
>>    int port;
>>    com.ietf.sip.contact contact;
>>
>> yields JSON of:
>>
>>    "port": 25, "contact": "...whatever..."
>>
>> We don't have to make things complicated!
>
>
> That is a model that I could very easily support as my tool is written in
> C#. In fact it already supports that kind of type label. All I would have
> to do is add in 'Using' specifiers at the top.
>
> The only thing it doesn't support are those semicolons. I find a carriage
> return is enough.

The details of how it's done are not important right now.  I only presented 
an example syntax as a way of illustrating what I'm proposing.

> Incidentally, this is what I meant when I said that discussion of the
> schema ideas and merger might be more useful than more proposals.
>
>
>> I disagree, I don't think the schema should address sub-syntax at all
>>> except for a small number of encodings that are RFCs such as RFC3339
>>> timestamps, URIs and DNS labels
>>
>>
>
>
>> I disagree with this.  Dates alone illustrate that there are
>> 'microformats' that can result in a much more compact, meaningful and
>> useful format than say:
>>
>>    { "date": 25, "month": 12, "year": 2015, "hour": 12, "min": 0 }
>>
>
> But we already have an RFC for Date - RFC 3339. (Actually we have others
> but we will forget those).
>
> So this is one of the microformats that I define in the tool as intrinsic.
> This also allows for the use of Integer encodings for DateTimes using
> seconds since the start of some epoch.

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?

>> Another location format might be:
>>
>>    56°14'23.45"N,18°5'16.65"W
>>
>
> { [56,14,23,45], [-18,-5,-16,-65]}
>
> Forcing such formats to be JSONified may cause as much error as forcing
>> IEEE 754 numbers to be decimalised.
>>
>
> It is certainly possible to do the job wrong but the above does not result
> in any loss of precision.
>
> The only case where I would feel comfortable with the microformat above is
> if the protocol was interfacing to some application where that format was
> already defined and translation between the formats would be needed.

Exactly.  That's the use-case - where the format is already standard for the 
domain in question.

> So let's learn from the past and recognise that we can't build them all in
>> upfront and design our format accordingly.
>
>
> There may be a need for a microformat. But that should be rare and should
> probably be specified in ABNF rather than the JSON schema.

Exactly.  It's saying there's something special here that is beyond my (the 
JSON schema's) ability to define.  It's also admitting that it's a rare case 
and the JSON schema doesn't want to be able to define it.  However, just 
because it doesn't want to do it, doesn't mean it wants to prevent you from 
defining something if it's useful to you.  EBNF with narrative in an RFC 
would be a suitable way to define it's format.

> In most real world examples you are going to get far more leverage by
>>> sticking to only encoding in JSON data model and then finding an 
>>> efficient
>>> way to encode JSON rather than inventing ad-hoc microformats that are
>>> neither JSON nor JSON data model, are going to require a custom parser 
>>> and
>>> are not going to compress.
>>>
>>
>> I'm not interested in compression beyond zip and co.  It may sound harsh
>> of me, but my feeling is if this or the errors in floating point numbers 
>> is
>> critical to you, then use something else.  We don't need something that 
>> is
>> all things, to all people.
>
>
> If someone is saying 'I only want text, space isn't important' then fine,
> just use text.
>
> But if someone is saying 'lets use JSON but then lets avoid making it too
> verbose using these microformats to shave a few bytes' then I would much
> prefer to just use an efficient encoding.

Microformats are nothing to do with minimising byte count.  They are about 
representing data in a natural form for the application domain.

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com