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

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

(trimmed)


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.

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.

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.



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


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.

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.

Unless dealing with text documents, LZ compression of an inefficient
encoding is not as effective as an efficient encoding in the first place.

If the threat of a binary encoding causes someone to withdraw an ad-hoc
microformat then its done its job...

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