Re: JSON, schemas & RELAX NG
> I am interested in defining the expected structureEarly on I designed a schema notation for JSON in JSON. But on
> of JSON objects in a way that can be programmatically
> introspected. Such definitions could be used for
> validation and for other purposes.
reflection, it didn't appear to do anything that an application
shouldn't already be doing in the process of checking its inputs. So,
it having little apparent value, I didn't implement it.
I think other people have had similar experiences.
If you think there is value in schemas in JSON, go ahead and implement
it. I don't think anyone is opposed to the idea. I just don't see a
lot of value in it, except perhaps for helping people who have been
indoctrinated in XML to take their first steps toward JSON. Maybe
there is value in that.
- Maybe a bit offtopic, but I have been playing with xmlrpc for a long, long time, and the very same question popped up now and then from different people.
Unfortunately there seems to eb no golden-bullet answer:
- xml schema is a real pain in the a### to use. People who master it are most likely not going to appreciate the simplicity of json anyway, but rather stick with SOAP beacause of all its enterprisey frameworks, automagic gluecode-generating kits and wide support
- relax ng is very cool, but as soon as you have implemented it, you find out nobody else but you has a toolkit that can take advantage of it
- a json-in-json type description language would be more appealing to the json crowd, but since it has not been written into the spec since day one, adoption rate risks to be very low.
In XMLRPC for example, most toolkit developers support a very crude type definition scheme, which has no provision for specificying recursive data (arrays, objects). A second proposition for a more detailed type scheme was made, but never adopted by anybody.
Imho the problem is every type definition language is too crude for some people (the "I miss a way to sepecify an odd integer value between -1 and 13" syndrome) and too complex for some other people (wsdl being a prime example - it is extremely complex on its own, but has no provision for a lot of stuff, eg. constraints that apply between two successive webservice calls, such as using a valid connection ID after retrieving it from the server, and now BPEL is poised to take opver and add even more complexity). The general trend being more bloat gets added with time.
Just my 2c
From: email@example.com [mailto:firstname.lastname@example.org]On Behalf Of hweingram
Sent: Tuesday, October 31, 2006 10:18 AM
Subject: [json] JSON, schemas & RELAX NG
I am new to the group.
I am interested in defining the expected structure
of JSON objects in a way that can be programmatically
introspected. Such definitions could be used for
validation and for other purposes.
As I understand it:
1. There is no equivalent of XML schema for JSON.
2. Where "schema-driven" functionality has been
implemented for JSON, it has typically followed
one of 3 approaches:
* XML schemas: Use schemas to describe XML, and
map the XML to JSON algorithmically.
* Based on RELAX NG: Claimed to be better than
XSL for JSON scenarios. Less broadly supported,
* Custom implementations
3. Is this an accurate description of the current
state of the art?
4. Is any consensus developing in this area? What
standard toolsets exist in this area?
5. Closely related question: is anyone working on an
extensible type mechanism for JSON?
Thanks very much for your thoughts.
[Non-text portions of this message have been removed]