Loading ...
Sorry, an error occurred while loading the content.

Re: JSON, schemas & RELAX NG

Expand Messages
  • Douglas Crockford
    ... Early on I designed a schema notation for JSON in JSON. But on reflection, it didn t appear to do anything that an application shouldn t already be doing
    Message 1 of 3 , Oct 31, 2006
    • 0 Attachment
      > 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.

      Early on I designed a schema notation for JSON in JSON. But on
      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.
    • Gaetano Giunta
      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.
      Message 2 of 3 , Nov 2, 2006
      • 0 Attachment
        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

        gaetano

        -----Original Message-----
        From: json@yahoogroups.com [mailto:json@yahoogroups.com]On Behalf Of hweingram
        Sent: Tuesday, October 31, 2006 10:18 AM
        To: json@yahoogroups.com
        Subject: [json] JSON, schemas & RELAX NG


        Hi folks.

        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,
        though.
        * 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.

        hw





        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.