Discussions

News: Danny Ayers: JSON missing a link?

  1. Danny Ayers: JSON missing a link? (13 messages)

    Danny Ayers has posted "JSON: missing a link?," referring to JavaScript Object Notation's lack of a DTD or schema that describes what objects actually are.
    There's no way of getting an arbitrary JSON document from the Web and knowing what it says - or even finding out. Sure, the browser can provide a view, but in that case the semantics of the document are taken from its presentation, which is a failure to separate concerns. You're at the mercy of the specific viewer implementation. (Would it be too cynical to suggest that part of the motivation behind HTML5 is a yearning for global semantics, and that standardising browsers is a roundabout way of providing them?). This in itself might not be that troublesome, other conventions/format registries (like microformats.org) could act as a substitute for the missing link. But there is something fundamentally unwebby about all this. If you need to have information in advance about the data for it to be useful, no matter how much lip service is paid to REST, your system is just as tightly coupled as if you were relying on named method calls. If you can't in principle switch say the social network input of your mashup from MySpace to Facebook without changing code to allow interpretation of the new source, then you're not really taking advantage of the Web, or for that matter gained very much over using WS-*.

    Threaded Messages (13)

  2. Re: Danny Ayers: JSON missing a link?[ Go to top ]

    I would actually say that useage has overtaken standardization and that useage has become the standardization that seems like the ultimate end goal that you are seeking. I guess its the difference between allowing the parties involved to be self organizing and self policing versus knocking them over the head with a semantic model and taking all of the concrete work energy into the ether of abstractions and models and the like. With something like JSON, which seems like it is getting huge uptake b/c of what it provides vs XML/XSD, that you could easily, if needed, use JSON as its own meta format ala XSD to describe a semantic model _if_needed_. In the end, whether you use JSON, or XSD, or DTD, if it changes and you don't account for it, it breaks regardless.
  3. Re: Danny Ayers: JSON missing a link?[ Go to top ]

    if needed, use JSON as its own meta format ala XSD to describe a semantic model _if_needed_.
    A programming language is a far better choice to define protocol payloads, either an artificial language like CORBA's IDL or any OO language like Java or C#. WDSL was a mistake.
  4. Re: Danny Ayers: JSON missing a link?[ Go to top ]

    maybe, maybe not ;-). I think the difference is when you get multiple platforms and languages into the mix, and you start looking at use vs standardization. My main point is that the protocol is standardized through useage and not the other way around. Granted, one can provide very strict semantics using IDL or WSDL or anything in a similar vein. However, there is a reason why JSON and other formats like are used more heavily in the wild, purely from an anectodal view point. Otherwise, every mash up and inside the firewall app would be looking up their taxonomies through a networked UDDI like structure and invoking SOAP everywhere.
  5. Re: Danny Ayers: JSON missing a link?[ Go to top ]

    I think the difference is when you get multiple platforms and languages into the mix
    Reflection solves that issue. It would be trivial to convert a JSON-spec written in Java or C# (or Ruby?) to any language using reflection, because the JSON semantics are a strict subset of any reasonable language. In theory, you could design a new description language like IDL, but I don't really see the point.
    My main point is that the protocol is standardized through useage and not the other way around.
    Sure. We basically agree. I'm not suggesting most uses of JSON should require an IDL/WSDL. But if you do want a formal description, or even if you want to describe a JSON protocol informally, you could use Java/JavaDoc or the C# equivalent as an easy way of documenting it. Programming languages are designed for that kind of thing; there's no need to invent something new.
    there is a reason why JSON and other formats like are used more heavily in the wild, purely from an anectodal view point.
    Because SOAP/WSDL is a screaming horror?
  6. Re: Danny Ayers: JSON missing a link?[ Go to top ]

    then I guess we are in violent agreement ;-). I see your point, which is something I wasn't focusing on since I am so hell bent on getting the big HAL baggage out of my life right now. A screaming horror? not always, just mostly ;-)
  7. If you need to have information in advance about the data for it to be useful, no matter how much lip service is paid to REST, your system is just as tightly coupled as if you were relying on named method calls.
    I didn't realize there were still people out there yammering on about 'self-descriptive' XML. What a crock.
  8. Where's the problem?[ Go to top ]

    If you want self-documenting, structure-authenticated and self-describing data from a source you don't control and that you may never have talked to before, then by all means go for XML. "Pleased to meet you Sir, how do you do?" If you control both sides of the conversation and want a fast, lightweight conversation, perhaps within an AJAX application, then you will be happy that JSON ditches all the redundancy and verbosity of XML. "Wassup man?" I think it's nice that we have a choice!
  9. Re: Where's the problem?[ Go to top ]

    If you want self-documenting, structure-authenticated and self-describing data
    How is XML more self-describing and self-documenting than JSON?
  10. DTD is no the magic bullet[ Go to top ]

    Take your pick from Schema/DTD/etc. These are all fundamentally constrained and superficial. If you want to verify the correctness of system-to-system messaging, there will always be necessary tests that can't be done with a simple structure check. Database calls are often needed. (Is this a valid customer? Is this a valid account? etc) DTDs also won't force a service author to make a reusable/flexible message format. It just enforces the structure of the current message format. That's a function of purposeful design and luck. Please keep XML Nazis away from a format whose functional purpose is quick, compact, dirty, and practical. Every book I see on XML is 500 pages long. Um, how? Oh yeah, the XML Nazis. Last thing we need is another bunch of standards bodies making up wonderful braindead stuff like XSLT and the five billion schema languages. Here's a hint, if you feel like you want XML's associated gunk, um, well, use XML.
  11. Re: DTD is no the magic bullet[ Go to top ]

    Take your pick from Schema/DTD/etc.

    These are all fundamentally constrained and superficial.

    If you want to verify the correctness of system-to-system messaging, there will always be necessary tests that can't be done with a simple structure check. Database calls are often needed. (Is this a valid customer? Is this a valid account? etc)

    DTDs also won't force a service author to make a reusable/flexible message format. It just enforces the structure of the current message format. That's a function of purposeful design and luck.

    Please keep XML Nazis away from a format whose functional purpose is quick, compact, dirty, and practical. Every book I see on XML is 500 pages long. Um, how? Oh yeah, the XML Nazis. Last thing we need is another bunch of standards bodies making up wonderful braindead stuff like XSLT and the five billion schema languages.

    Here's a hint, if you feel like you want XML's associated gunk, um, well, use XML.
    I agree with your point that schemas are not enough. But I don't think these things have no value. The biggest benefit of a schema is that it's a unambiguous document that both parties can use to communicate the structure a document. The second benefit is that it's a rough check of input before really validating the data. Once you have run the document through the schema validator, you can make a bunch of assumptions about whether fields are there, whether they will parse, etc. It won't do everything but it's useful all the same. I also have to say that XSLT is a really powerful tool and much better for transforming data than using an imperative language. On a side note, it seems to me with just a little magic, you could make tools built for XML work on JSON data.
  12. Re: DTD is no the magic bullet[ Go to top ]

    Yo, i need to agree that Schema and DTD does indeed help. Without Schema/DTD i would have a base XML document and JSON text are same (in my view). With the help of Schema/DTD there is a great sense of "semantics" applied on xml, to parse and understand it in the correct way by an application. I would use JSON ONLY as a light weight protocol for data transfer, but not as a metadata representation format for applications. And also i am happy to use JSON in this way without complicating it by introducing all the different usecases from XML. Like XPath, XQuery, XRef, DOM, SAX etc...
  13. Interfaces[ Go to top ]

    ... as an architect, I value schema (schemae ? schemas ?) because they document and enforce the interfaces that must be used for integration. And that's huge. I don't think it's an exaggeration to say that documented and enforced interfaces are necessary for long-term enterprise development. Are schema tedious ? Absolutely. In my opinion, though, any exact and significant interface documentation will be tedious - that's why people usually don't create it. Obviosuly this does not mean that all people have to use schema (or documentation of any kind) at all times. There are always more little short-term systems being built than large long-term systems. I do think that it is hard to tell which will turn out to be which ;-) but that's the risk we take ...
  14. Re: Interfaces[ Go to top ]

    It's interesting how these discussions are evolving. Personally, what I am seeing is a big difference between application to application integration both intra/inter organization and integration across enterprises (counterparty entities/different business entities). On the one hand, we are exposing certain trading services via WS/SOAP/XML/XSD with a very well defined schema for those outside our firewall. However, we are more than willing (actually prefer) the same integration using a different payload format (JSON), partly b/c it is/will be there to begin with, and also b/c it puts less burden on our overall infrastructure to consume (all paths lead to the same validation routines, whether they pass schema validation or not, meaning, XSD conformity is the javascript function in a web page that says your email address has an _at_ symbol). On the other hand, we have applications that push out real time ticks over lightweight messaging to other applications within the enterprise, but across organizational boundaries and firewalls. These do not use XML, and instead use JSON when the payloads are larger (e.g. a bunch of forward tenors) and only message headers when its just a simple tic. How do we define the interfaces for these apps? We document them, and when there is a problem, they pick up the phone, or we meet (yuck) to explain it, and test, which isn't that different than what we would have to do otherwise. What we gain is a smaller form factor in the payloads, simpler human _and_ machine readability, and less headaches following XSD schema restrictions down the promise of semantic purity and then realizing that there's only so far you can go down certain paths with XSD. All in all, I think we will see more and more uptake of non-xml formats.