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

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

Expand Messages
  • Tatu Saloranta
    ... Ok. I did notice extends property (but only after sending email), which when combined with other pieces should allow for defining type structures? ...
    Message 1 of 8 , Apr 27, 2009
      On Mon, Apr 27, 2009 at 2:25 PM, Kris Zyp <kriszyp@...> wrote:
      > Tatu Saloranta wrote:
      >> One thing that is currently missing (AFAIK) from JSON stack is the
      >> equivalent of useful parts of W3C Schema ("xml schema").
      > 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.

      Ok. I did notice 'extends' property (but only after sending email),
      which when combined with other pieces should allow for defining type

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

      Basically I am thinking of supporting both schema-first model
      (generaring classes/stubs from definition) and code first (annotating
      to produce schema).
      And for Java, perhaps generate bean-validation annotations, for schema
      first case.

      Perhaps what would be nice would be more along the lines of providing
      more convenient syntax to express already defined json schema model.

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

      Probably not -- initially I just missed it. :-/

      It does however need to be coupled with some definition of how to
      include type identifier in json content ("#type" field? standard name,
      or perhaps configurable with schema). Is there something in Json
      schema to define this? Or if not, could it be added?
      Type is needed to deserialize specific sub-type instance; on
      serialization full type is known, but on deserialization only declared
      type, and full type needs to be available from json content (can
      optimize this out for leaf types).

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

      True, I should have clarified that. This would be the data/type model
      that is useful (and sort of required) for WS, but specifically not the
      web service definition itself (no end points, operations etc defined).
      Like XML Schema part that Soap/WSDL build 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.

      Ok, thanks. Sub-setting could definitely work. I need to read json
      schema proposal with some more thought. I am interested in syntax
      part, as well as some limitations on what kinds of schemas would be
      allowed -- certain kinds of unions might not be representable on OO

      Also: is the use of json as format for schema a fundamental goal? To
      me it seems that there are benefits to using more compact and
      expressive notation, but not much benefit from using JSON (i.e.
      complexity is not within parsing of schema but in processing it).
      I don't mind having a json serialization (RelaxNG - like "dual"
      model), but really like the idea of having something more optimal for
      the domain.

      -+ Tatu +-
    Your message has been successfully submitted and would be delivered to recipients shortly.