Discussions

News: JSON visualization plugin for Eclipse

  1. JSON visualization plugin for Eclipse (16 messages)

    JSON - JavaScript Object Notation - can be cryptic and difficult to read if not clearly formatted, so Suresh Krishna wrote a visualization plugin for Eclipse. The plugin allows users to see JSON represented as XML or as a hierarchical tree, as well as determine if the JSON is invalid. The project can be found on Sourceforge, and the plugin is referenced on Eclipse' plugin central site as well.
  2. Is it me or is JSON an awesome solution for people responsible for the technical implementation of resource-or-service based systems. But if your a vendor, it's difficult to make money from - it's too simple (how do you make the simple simpler?). Which explains the enthusiasm developers have and the lukewarm response from non-developers.
  3. Re: JSON visualization plugin for Eclipse[ Go to top ]

    It's not you ;-), very good point you have there.
  4. In my view a lot of WEB2.0 companies have adopted the JSON. Yahoo, Google, IBM, JackBe are some of the companies that i know who play a lot with JSON. Of course the usage could be internal consumption or exposed as web service response format. In the end definitely its a good question, if we could sell a product as its based on JSON. But i have seen that its more easier to consume for the WEB 2.0 developers as its JavaScript can eval() it directly. So its more of a standard and complements the WEB 2.0 technology.
  5. Good job Suresh! I can understand why you needed such a plugin ;-) I noticed your plugin uses the standard json.org classes, taking the risk of a shameless plug I must say that Json-lib 2.x has greater support for JSON XML conversions, even with namespace support if required.
  6. Is it me or is JSON an awesome solution for people responsible for the technical implementation of resource-or-service based systems. But if your a vendor, it's difficult to make money from - it's too simple (how do you make the simple simpler?). Which explains the enthusiasm developers have and the lukewarm response from non-developers.
    JSON is a bit of an interesting duck. JSON (by some arbitrary measurement) covers most of everything you need, while SOAP covers it all and more. As soon as you need something above 80%, you may be screwed. No object references, data types or data structure definition. The plus side is, it's easy to parse, the APIs pretty much break it down to dictionaries and arrays in a nested fashion. Everything else is left up to negotiation, which can be bad. Two people integrating is easy, but get a very large team and the finest of details may become important and lost. Documentation is key with JSON. I think it may be the larger, broader, infinite future people ignore, miss or place aside for future evaluation. The what if I need X someday, which may never even come to pass. Feels like MySQL all over again damnit. :)
  7. Two people integrating is easy, but get a very large team and the finest of details may become important and lost. Documentation is key with JSON. I think it may be the larger, broader, infinite future people ignore, miss or place aside for future evaluation. The what if I need X someday, which may never even come to pass.

    Feels like MySQL all over again damnit. :)
    Two people - Google heavily uses JSON and there's more than just 2 people using their api's. Documentation? Google's apis are about as simple as can be. On the other hand, I've worked with BPEL, WS-* whatever on a number of projects that had, at most, 3 clients. Oracle and IBM do a great job selling that stuff, but it's all mostly a waste of time.
  8. Two people integrating is easy, but get a very large team and the finest of details may become important and lost. Documentation is key with JSON. I think it may be the larger, broader, infinite future people ignore, miss or place aside for future evaluation. The what if I need X someday, which may never even come to pass.

    Feels like MySQL all over again damnit. :)


    Two people - Google heavily uses JSON and there's more than just 2 people using their api's. Documentation? Google's apis are about as simple as can be.
    I see what you did there. You projected a successful, well written implementation of JSON over all JSON projects. If I gave you a field like, "date" => "01/01/2000", is it in GMT? What's the timezone? That's an example of something SOAP addresses ala the datatype spec. SOAP isn't perfect. There are holes in it. It tries to leave out ambiguity where JSON is a free, very simple spec that anyone can implement to suit their needs. Heaven help you if you pick the wrong one for the wrong job. Moving from SOAP to JSON may be a little easier, though the other way around doesn't seem so straight forward. SOAP is a bit of a horse that benefits from having some experience and knowledge in it.
  9. Re: JSON visualization plugin for Eclipse[ Go to top ]

    interesting point. I think that as with others, wider adoption, as well as the velocity and acceleration, basically starts to make this more and more of a defacto std in the wild, then other "real" stds that are under the WS-* umbrella (which by now is not just an umbrella, but a very big circus tent with smelly elephant droppings). I think the beauty of JSON (and things like it) is in its malleability. Yes, you can't do all of the nifty things you can with xsd, however, in practice, I've found that integrations inside the firewall are starting to look at the format as an alternative to XML, which is intriguing. What we really need are more and more libraries such as json-lib and others. If I had a nickel for every failed WS-* based initiative in the enterprise, I'd be typing this from bed instead of the my commuter train to work.
  10. Re: JSON visualization plugin for Eclipse[ Go to top ]

    Yo, i think its not right to compare the XML and JSON directly. Once i have seen both the worlds, i feel there is some sort of the semantics that is missing or to be improved in the JSON. I recently seen that the json-lib has done a good job regarding the JSON XML conversion. At this point of time i see JSON sa just a interchange format for WEB applications. And that too for small amount of data.
  11. As soon as you need something above 80%, you may be screwed. No object references, data types or data structure definition. The plus side is, it's easy to parse, the APIs pretty much break it down to dictionaries and arrays in a nested fashion. Everything else is left up to negotiation, which can be bad.
    First, everything in inter-organizational communication is negotiated. Just because you've got a schema or a WSDL it doesn't mean that there's nothing to negotiate. At the very least you will need to negotiate so agree on that schema. The only way you can avoid it is to produce a very detailed spec and say, "you will follow this or we won't be talking" which is pretty annoying and doesn't work if the company on the other end is important enough and has their own ideas about things. Secondly, it seems to me that really wouldn't be hard to get a XML verifier to validate data that came from a JSON document. There's nothing that I am aware of that you can represent in JSON that you can't represent in XML and most of the time you'll never seen any other stuff you can't do in JSON in XML anyway. For communication purposes, I see them as pretty much equivalent. Validation is a function of parsing and processing, it's not inherent to the document or it's format specification. There's nothing that makes XML more easy to validate than JSON. I'd actually argue it's the opposite because XML allows things that are more complex (and generally useless for inter-organizational communication). On a side note the idea that you would specify your validation schema in your document has always seems pretty damn stupid to me, at least for communication. I'm going to validate the document based on the suggestion of the person that sent it? Right, that couldn't ever cause any issues like say, huge security holes. Every time I see a DTD or schema reference in an XML document I want to slap the person that put it in there. It's just something I'm going to remove before I work with it.
  12. I don't know how we veered off of SOAP to plain XML.
    First, everything in inter-organizational communication is negotiated. Just because you've got a schema or a WSDL it doesn't mean that there's nothing to negotiate.
    Some vendors don't negotiate because it already has a few hundred users using the current setup. They usually provide jars and other forms of their libraries in case you run into trouble.
    There's nothing that I am aware of that you can represent in JSON that you can't represent in XML and most of the time you'll never seen any other stuff you can't do in JSON in XML anyway. For communication purposes, I see them as pretty much equivalent.
    Agreed, and going from JSON->XML may require some handling in the case of object graphs and cycles.
    There's nothing that makes XML more easy to validate than JSON.
    SOAP spec dictates what data types are available in the XML message as a base. There is a high level of validation for structure and data. Makes data mapping a lot easier too. Nothing so minute to say, you're passing in prime numbers, but at least you can stop people from giving you irrational numbers when you are looking for primes. :)
    Every time I see a DTD or schema reference in an XML document I want to slap the person that put it in there. It's just something I'm going to remove before I work with it.
    If you are working tightly between two persons, all that extra specing out may be completely unnecessary. Take integrating two java apps that are in two separate offices that can't share a DB. Sure, JSON is perfect for it. Schema and DTDs are great for high level validation to weed out completely ridiculous answers. It's a safety check against glaring errors, such as passing numbers as strings, or vice versa. Or nesting the wrong things in the wrong places. It's for making XML files a little more specific. Sure, you may not need it. Great. For some people/projects, it's needed, or at least desired. It makes their lives easier. Lots of choices and flexibility in our tools is a good thing.
  13. I don't know how we veered off of SOAP to plain XML.
    Sorry, I see SOAP (a.k.a XMLP) as just another standard for XML out of a huge field. SOAP is XML and generally, what I've seen when it's used is just a plain XML document inside a SOAP envelope. Trying to use any other parts of SOAP just caused customers and vendors to whine.
    First, everything in inter-organizational communication is negotiated. Just because you've got a schema or a WSDL it doesn't mean that there's nothing to negotiate.


    Some vendors don't negotiate because it already has a few hundred users using the current setup. They usually provide jars and other forms of their libraries in case you run into trouble.

    I worked at a company where we had lots of customers, lots of setups and most customized standards for their own purposes. Even if you stayed inside the standards, you still had to agree on what things meant. Our vendors required we use their format so we had to support a lot of formats on that side too. What you are talking about only works on one side of the equation and I'm sure if you are the bully, it seems really simple. The other side is stuck with supporting yet another thing. And if your have two companies that demand the other use their format, that's a fun power-struggle to watch.
    SOAP spec dictates what data types are available in the XML message as a base.
    Does anyone actually use that stuff? Passing 'objects' around in XML is a pretty flawed concept, if you ask me. It's very limiting and suggests a particular solution that isn't necessarily a good one. Messaging is much more robust.
    There is a high level of validation for structure and data. Makes data mapping a lot easier too.
    How's that? This would seem to be a function of the tools, not the document.
    Every time I see a DTD or schema reference in an XML document I want to slap the person that put it in there. It's just something I'm going to remove before I work with it.


    If you are working tightly between two persons, all that extra specing out may be completely unnecessary. I think you are missing the point. What I am saying is that the validation is a done by the reader in the way the read decides they will do the validation. There's nothing stopping anyone from validating JSON just as rigorously as one can validate XML. And from an application level, it shouldn't matter how the data was serialized. You seem to be suggesting that XML or SOAP can be validated in ways that JSON cannot. I don't think that's the case for most intents and purposes. My point is that it's six-of-one a half-dozen of the other. The formats are roughly equivalent, it's how you use the data that matters.
  14. I worked at a company where we had lots of customers, lots of setups and most customized standards for their own purposes. Even if you stayed inside the standards, you still had to agree on what things meant. Our vendors required we use their format so we had to support a lot of formats on that side too.
    Think you can do that easily w/ say, Google? Or salesforce? Sure, it depends who needs who more. I doubt google needs a single mom and pop shop if everyone else is willing to work the way google has established.
    Does anyone actually use that stuff? Passing 'objects' around in XML is a pretty flawed concept, if you ask me.
    I've seen frequent enough use of it to 'least say it is used.
    How's that? This would seem to be a function of the tools, not the document.
    The definition of the data passed is built into SOAP. Sure, one could do the same for JSON by testing that a date was passed and is valid, then convert it. Yes, the tools for SOAP can have the same done automagically. SOAP is the only protocol that allows that automagic stuff to even happen.
    I think you are missing the point. What I am saying is that the validation is a done by the reader in the way the read decides they will do the validation. There's nothing stopping anyone from validating JSON just as rigorously as one can validate XML.
    That's certainly not the point. Sure, it can be done by the person who writes a JSON based thing, but SOAP provides support to allow tool writers to take that away from the user in the tools they provide. If one has to integrate tightly over a large set of varying data structures being passed, I'd have to write that many validators. Sure, SOAP is only XML, but it's XML used with a specific purpose, but it's also a contract on a subset of structure. The meta-data of what is going on is preserved.
    You seem to be suggesting that XML or SOAP can be validated in ways that JSON cannot. I don't think that's the case for most intents and purposes.
    Oh come now. Of course anyone can get the value and make sure an certain structure is there. That's not what I'm implying. There's less context provided in JSON which makes it the worst and best thing ever. Simple to use in really simple ways, for simple needs.
  15. I worked at a company where we had lots of customers, lots of setups and most customized standards for their own purposes. Even if you stayed inside the standards, you still had to agree on what things meant. Our vendors required we use their format so we had to support a lot of formats on that side too.


    Think you can do that easily w/ say, Google? Or salesforce? Sure, it depends who needs who more. I doubt google needs a single mom and pop shop if everyone else is willing to work the way google has established.
    You response seems very odd too me. It's like you are arguing with me and making the same point I made. My point is that not everyone is Google. Not everyone is talking to Google. Apple might want to talk to Amazon, for example. small.com might want to talk to little.com. and then there was where i used to work that was a customer a vendor and things that were somewhere in between with literally thousands of companies to communicate with, large and small. The big companies were the ones that caused all the headaches. They wanted everything customized for them and would not customize anything for us. There servers would choke on 10 incoming connections but they would complain bitterly if we didn't handle their 750,000 messages in short order (which is hard when their server can only handle 5 incoming connections.) The big companies aren't always the smartest or best. Sometimes they are just the biggest dickheads.
    Does anyone actually use that stuff? Passing 'objects' around in XML is a pretty flawed concept, if you ask me.

    I've seen frequent enough use of it to 'least say it is used.
    Never used it, never wanted to. No company we worked with wanted to either. It was passé years ago.
    SOAP is the only protocol that allows that automagic stuff to even happen.
    Nonsense. Any schema defines the structure of a message. It's WSDL that really that makes WS* standards useful and it's not really specific to SOAP.

    I think you are missing the point. What I am saying is that the validation is a done by the reader in the way the read decides they will do the validation. There's nothing stopping anyone from validating JSON just as rigorously as one can validate XML.


    That's certainly not the point.
    Are you seriously telling me what my point is? That's pretty crazy.
    Sure, it can be done by the person who writes a JSON based thing, but SOAP provides support to allow tool writers to take that away from the user in the tools they provide.
    And you don't think a similar protocol couldn't be developed for JSON? SOAP isn't even that great of a protocol for communication between organizations. It's not suited to the task it's used for.
    That's not what I'm implying. There's less context provided in JSON which makes it the worst and best thing ever. Simple to use in really simple ways, for simple needs.
    This is what I don't understand about your argument. You agree that they XML is basically equivalent to JSON for messaging and then say this. There's no more context in XML than you add to it. Yes there are a lot more protocols for XML (too many, probably) but protocols can be created in short order.
  16. Can someone visualize how this visualization looks like? Maybe post a screenshot. Isn't it too much to ask? :-)
  17. you can get 2 screeshots from the following link... http://sourceforge.net/project/screenshots.php?group_id=205573 any feedback and comments are welcome... :)