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

1238Re: [json] Need for "abstract data model" to support JSON, web services ("useful parts of w3c schema", not validation)

Expand Messages
  • Kris Zyp
    Apr 27, 2009
    • 0 Attachment
      Tatu Saloranta wrote:
      > One thing that is currently missing (AFAIK) from JSON stack is the
      > equivalent of useful parts of W3C Schema ("xml schema").
      > I know there is a JSON Schema effort underway already, but if I
      > understand things correctly, its focus on validation aspects, and not
      > data typing or modeling .
      > Although w3c Schema can be used for that (as can DTDs and RelaxNG,
      > latter of which does this better), to me the main value of Schema is
      > as abstract data typing/model.

      JSON Schema can certainly be used for that purpose, I am using JSON
      Schema for typing in Dojo and Persevere, and not just for validating
      existing JSON structures.

      > What I mean by this is that the only real advantage of, say, SOAP over
      > similar simpler JSON+Rest approach is that of having language-agnostic
      > data model that can be used for full object binding and serialization;

      I am not sure if this exactly what you are talking, but we have been
      discussing using JSON Schema as a way to define hyperlink properties in
      JSON structures to provide interoperability in RESTful JSON:

      > including code generation if need be. You can (painfully) define such
      > model, and then generate or bind conforming data to objects.
      > This helps in interoperability as you can describe data content in
      > language+platform independent way, but with ability to get specific
      > bindings reliably.
      > With JSON you can already do data mapping/binding quite well, except
      > for one area of problems: that of handling polymorphism (inheritance).
      > Although that can be worked around on language-by-language basis
      > (adding "class" element in Maps), there is no generic way to do it.

      The "extends" attribute of JSON Schema is designed specifically to meet
      the needs of describing data structures with inheritance. Is this
      insufficient for your polymorphic description needs?

      > Another thing that I feel most existing Schema languages get wrong is
      > the false goal of having to be expressed in format being described
      > (XML schema written in xml). Instead, notation absolutely should be a
      > DSL: right tool for the job. This is especially crucial for JSON
      > because of its simplicity: trying to shoehorn a definition language in
      > JSON seems unnecessarily cumbersome.
      > It is ok to have a one-to-one mapping between optimal DSL and JSON (or
      > xml) if need be -- RelaxNG shows a good way of doing that with its
      > compact (non-xml) notation, and equivalent XML serialization.
      > So I would be interested in finding a solution for this problem -- it
      > seems like the last missing selling point for JSON-WS, to be used for
      > the use case of external entities communication over such an interface
      > (less needed for internal integration where more concrete interfaces,
      > client libs etc, can be used).

      "JSON-WS" hints more at RPC type communication, which is what SMD is
      designed for (which uses JSON Schema):

      > One more thing: defining such a notation might not be extremely
      > difficult -- since validation is NOT the main focus, range & size
      > limitations could be omitted, or kept very simple; more important is
      > JSON-primitive/object-inheritance data-typing and structural
      > definitions.
      > Validation aspects can be handled separately; or as an add-on.

      JSON Schema can as simple as the subset you want to use. {} is a valid
      schema (although not particularly useful). We have discussed formally
      defining a subset of JSON Schema for more traditional data-typing style
      constraints, but when after some discussion of how easy it is to ignore
      non-relevant parts of the spec, it seemed like kind of a silly exercise.
      Of course, if you want to define a non JSON-based data type modeling
      system, that is indeed a completely different matter and exercise. Or
      maybe I am missing what you are really after.

    • Show all 8 messages in this topic