Re: [Json] JSON Concluded? Well, maybe not

I have a schema language that I use to generate Web Service clients and
services. The implementation is open source. It also generates reference
sections for an Internet Draft:

http://www.prismproof.org/Documents/draft-hallambaker-mesh-reference.html

Right now I have three separate schema languages that were written at
different times to target XML, JSON, ASN.1 and TLS style encodings. 90% of
them are the same.

What I think really commends JSON is the lack of extraneous information in
the schema. Let us say we are serializing an integer. In the TLS schema I
have to specify whether it is an 8, 16, or 32 bit, signed or unsigned, etc.
In JSON its just an integer.

I just want to think about my application, I want the serialization to be
as straightforward as possible. What I don't need or want is the type of
capabilities XML Schema gives me, the ability to specify that an integer is
greater then 4 and less than 23. That is not information I have ever found
the need to express in a schema and I have been using this approach to
generate protocols for 25 years.

What I have now is adequate for my needs right now. If there is interest in
a standard, I would probably want to clean up the approach and make it more
regularized.

On Sun, Dec 31, 2017 at 1:50 PM, Tim Bray <tbray@textuality.com> wrote:

> If I were going to make an argument for keeping the WG alive, it would
> require someone to get energized and submit an I-D for a plausible JSON
> schema system, or maybe even a much-needed formalization of JSONPath. We
> use JSONPath a lot at AWS.
>
> On Sun, Dec 31, 2017 at 10:43 AM, Richard Gibson <richard.gibson@gmail.com
> > wrote:
>
>> On the topic of JSON normalization, I believe that canonicaljson-spec
>> <http://gibson042.github.io/canonicaljson-spec/> covers all cases while
>> respecting prior art like https://tools.ietf.org/html/dr
>> aft-staykov-hu-json-canonical-form-00 and RFC 7638. I'd like to get it
>> published as an RFC to handle scenarios like those mentioned by Anders
>> Rundgren, but am not sure how to go about doing so. Is this a good place to
>> ask for assistance?
>>
>> On Sun, Dec 31, 2017 at 12:24 AM, Anders Rundgren <
>> anders.rundgren.net@gmail.com> wrote:
>>
>>> Congratulations everybody to the revised JSON RFC!
>>>
>>> Does this mean that JSON is "done" for good?
>>>
>>> Probably not because the concept I have mentioned from time to time, the
>>> ability adding a digital signature to a JSON object (in contrast to signing
>>> arbitrary Base64Url-encoded data), is still very much alive.  In fact,
>>> there is an I-D in preparation aiming at reducing the current proliferation
>>> of "DIY-standards" for dealing with this highly requested feature.  The
>>> only real challenge is agreeing on a suitable way "normalizing" JSON data
>>> during parsing and serialization.  Such a scheme will be like an extended
>>> version of I-JSON (RFC7493), potentially having an impact on "ordinary"
>>> uses of JSON as well.
>>>
>>> Happy New [and optionally signed] JSON Year
>>> Anders Rundgren
>>>
>>> _______________________________________________
>>> json mailing list
>>> json@ietf.org
>>> https://www.ietf.org/mailman/listinfo/json
>>>
>>
>>
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json
>>
>>
>
>
> --
> - Tim Bray (If you’d like to send me a private message, see
> https://keybase.io/timbray)
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>
>