Andrea Trasatti

Hi David,
I agree with you on the simplicity and “compactness” of JSON.

I think that your proposed format does not solve the problem of HOW to describe things, that’s a big topic in RDF and it’s defined as a vocabulary. No matter what structure you use to describe things you will still need a vocabulary and in your example you are implicitly accepting the one from FOAF ( http://xmlns.com/foaf/spec/ ).

I am not in favour of RDF or JSON in this case, but I think that in order to have an accepted Practical JSON Format Standard you need more, in fact, I don’t understand why this is more “Practical” than anything in JSON.

I am unclear what your ambition is, make JSON accepted as a format to describe things in place of RDF? Isn’t it already?

John Keyes

Good idea. I always look for JSON when integrating with a new API as it’s so easy to work with, and so easy for a human to scan.

I’ll be interested to see where this is going, and seeing if it can make my life even easier.

David

@andreatrasatti I do not want to have a port from XML standards because they XML standards are rather complex for what has to be achieved. For machines they are great but for the average developers, they are bloated.

The practical part in this is that instead of having random json generated objects by webservices. I am not trying to solve the “How to describe things” problem because I believe none will ever be able to do this, what I’d like instead is a way to name objects, properties, array keys, etc. The practical part comes in when you keep the format standard to the basics. Instead of trying to handle each edge cases, trying to cover the basics, what developers use, what developers want. That is when the practicality of the idea comes in.

However I do agree that no matter the data interchange format, describing things will always be a problem and this no matter who’s doing it, describing it.

What really sparked me is the likes of laconi.ca that mimicked the behavior of the Twitter webservice. I realized that there’s nothing out there for the “zillions” of web developers using JSON.

Iarfhlaith Kelly

I think you’ve hit the nail on the head here David.

1. JSON is the best way to interchange data between client and server.

2. Semantic data formats will become more prominent as developers become more reliant on 3rd party data and services. Something that’s already happening.

In the words of Joey Tribbiani, “Put your hands together!”.

These two standards were bound to cross paths eventually, and I think that the sooner that happens the better. It’ll make life easier for us (the developers) and boost the adoption of semantic data across the Internet, which will benefit everyone.

Fair play on this proposal, I think it’s a great idea. If you need some extra help, just shout.

Enda Madden

Great post. How do you feel this would complement or sit with Microformats such as XFn that describe peoples relationships?

David

@endamadden I’d love to see some kind of “mix” between existing microformats and XFn but in JSON. Some kind of “bridge” or simplified mix could be quite interesting.

I’ll have to contact Joseph Smarr (portable contacts) and Tantek about a good discussion about this.

I think JSON has been ignored in terms of standards for a while and something that developers can actually make sense of AND make effective use of would be very cool

At this point now it’s about gathering interested bodies, and starting to discuss things, have a few fights with evangelists, pick which fights and try to get something practical out of the idea.

Ross Duggan

David, this seems like one of those so-obvious-it-should-already-be-done ideas

The idea of JSON formatting standards feels to me like would be a move towards a sort of generic web application API language, which is an exciting prospect.

I’d love to pitch in where I can.

[...] Practical JSON Format Standard - David Coallier at the EchoLibre blog puts forward a proposal for a set of standards for JSON formatting. This has the feel of something that could explode into something powerful, watch this space. var addthis_pub = ‘rossduggan’; var addthis_language = ‘en’;var addthis_options = ‘email, favorites, digg, delicious, myspace, google, facebook, reddit, live, more’; [...]

Dave Concannon

“It’s there to create standard object names, properties, variables, class members names to JSON elements so that developers can expect something identically formed when requesting JSON information from a webservice..”

I’m also slightly puzzled by what you’re trying to achieve… Is it that you want to mirror current XML-based standards in a JSON format, or specify something along the lines of a specific notation for JSON formats (hungarian notation / variable typing etc)?

The latter just seems like a reasoning for good API documentation. JSON is a fantastic, easy to use format, but I don’t think you can save a bad API with better variable names.

David Coallier

@daveconcannon Hey Dave, I’m glad you asked

What I want to see is not a port of XML standards to JSON. If I wanted to do this, I’d simply use jsonml.org. However, the concepts behind the XML standards are very good I think they do not really apply to your average day-to-day web developer and they mostly seem to be used by theoriticians.

What I want to achieve here is a practical naming standard. If it has to be derived from some XML standard be it. But what I want to see is a set of object/property naming convention that will fit the actual real world with simple and easy to understand standards.

I have to disagree with you, I think you can indeed save a bad API with better objects/properties/variables names. What makes an API bad (Else than it’s lack of developers consciousness, documentation, poor performance, etc) ? It’s the format in which the data is returned to you. If you adhere to a JSON object naming convention (or any standard for that matter), you can thereby resolve the suckyness of an API.

Hungarian notation, camelcase, etc would most likely be part of the standard, but I think that both actual naming of objects and properties and how they are written (naming convention) should be covered. Imagine the following: You have all microblogging networks returning JSON data in their own ways. That’s fine but that means that your developer needs to learn each of those in order to be able to communicate with them. That means he has to spend more time reading documentation for each service, using different libraries to query each service, etc.

By bringing in a standard, in my case a light JSON standard, you rectify this situation by making sure that the developers only have to learn one thing and that each networks they are interacting with are going to return the same data with the same structure, thus when decoding the JSON object, you know what to expect, therefore saving you time and money.

Site “a” returns information about someone that way:

1
2
3
4
5

{
    "people":{
        "fname":"david"
    }
}

Site “b” returns information about someone as well, but that way:

1
2
3
4
5

{
    "person":{
        "fn":"david"
    }
}

And site “c” returns the same information that way:
Site “b” returns information about someone as well, but that way:

1
2
3
4
5

{
    "Resource":{
        "firstname":"david"
    }
}

Wouldn’t it be easier for everyone if a practical standard for naming the object and their properties for a situation be established? One could argue that you could port XML-based standards but in reality they are often bloated and a overhead for most developers to learn.

So consider if all sites would return the data that way:
Site “b” returns information about someone as well, but that way:

1
2
3
4
5

{
    "person":{
        "firstname":"david"
    }
}

I agree that this is not going to resolve each problems in the world, but it seems obvious to me that something important is missing for developers at the moment.

Iarfhlaith Kelly

One more thought on this:

XML is a self describing language and part of the problem I think you’re talking about here is that people aren’t ‘describing’ their data in exactly the same ways.

Isn’t this versatility the whole point of a self describing language? Allowing it to be flexible enough to suit whatever data it needs to represent?

Dave Concannon

@David

If you’re talking specifically about the representation of a user or other common data in the web service / application etc, that could be useful. But, discarding XML standards just because they’re bloated (they are) seems to throw the baby out with the bath water. They’ve already been designed to accommodate all the information that the situation requires in a structured way, and have a naming standard. The majority of the bloat are edge cases, which are usually optional elements.

I think the idea is good, but how much standard info is there that isn’t covered by the structure of FOAF? Beyond user information etc a lot of site data is independent.

On a tangent, I think good naming will improve an API only if the documentation is dire. A good API can exist with a terrible naming structure, providing the data it returns is relevant to the request (e.g. you ask for a user, you get all the relevant user info, not additional unrelated bits that the API developer thought was a nice idea, or have to make a subsequent query for something that’s immediately relevant).

This is all more of a dialogue though, I think that the worst that could come out of this is a great discussion on structured APIs etc and how developers use them, which is worthy in itself.

David

@iarfhlaith The problem you are mentioning is a problem that standards have in general. For XML it’s great that it’s flexible enough to describe everything in your own way, but when data starts repeating and common tasks are being described in their own ways, then you need a standard.

David

@daveconcannon I think you’ve hit the nail right there:

I think the idea is good, but how much standard info is there that isn’t covered by the structure of FOAF? Beyond user information etc a lot of site data is independent.

The fact is that most standards like FOAF are getting old. With the current trends with microblogging for instance, a standard for them should be put in place for the way they represent their user data (friends, etc). Another easy standard I can think of is for online stores. Each online store displays their data in their own ways. If they’d all agree on a standard to distribute data, they’d have a bigger adoption (or at least happier developers).

I don’t think scrapping existing XML-standards is a good idea, but adjusting them to real world use cases and day-to-day developers life could bring a much awaited adoption of those standards.

As someone said above, have JSON standards that are usable by everyone without having to understand the overwhelming complexity of existing XML standards could very well be the bridge we are looking for from the “Do everything yourself” to “Complex XML standards”. It could generate an interest for standards. An interest that is sadly lacking nowadays.

Richard Harrison

I don’t see the practical value.

If I’m consuming multiple micro-blogging data sources then I’ll have to write code to deal with the nuances of each of their services even if their payload format is the same (authentication, request formats and so on). Given that they’re in the same domain and they’re both publishing JSON data, their payloads are not likely to differ so much that it’s going to be hard work for me to consolidate/abstract their formats within my application.

I think this is going to be a lot of hard work to setup and to gain traction, for not a great deal of return. Just thinking of the political bullshit that you’re going to have to deal with makes me glad it’s not me :-).

David

@Richard Harrison Haha I think you are right about the fact that we are going to be hitting many political issues and also be shattering many egos in this but I really do believe that there’s a missing link between developers and XML Standards.

I see what you mean by particular issues - nuances with each services but that’s a problem that can’t be resolved. As long as humans are going to be involved it’s not going to be resolved

If you do for instance compare the friends on each networks though you could easily do it with the same friends formatted data. Same goes for sites selling products.

But again, I’m sure politics will come into this, they always do and with anything that is public and used, people have opinions (thank god for that) and they have to be respected - listened.

Tim Parkin

http://json-schema.org/shared.html

Are you proposing something different to this?

David

@Tim Parkin Actually they are doing precisely it Not sure why it’s not globally known or why their SEO is so bad :O

I’ll definitely get in contact and see if we could contribute in promoting and developing the standards!

Good find

David Doran

I’m interested…the whole standards issue intrigues me but I’m also weary about picking a path which ultimately pidgeon-holes us.

I agree that XML can seem wasteful when you look at all those repeating tag names and verbose self-describing features. JSON, however (while it can) generally doesn’t include any indication of what the data means, of course. That’s a weak argument though, because as developers we’d rather have SPEED and light-over-the-wire communications.

What more concerns me is the following;
* Developers always want to add something,
* Developers far too often re-invent instead of augmenting.

If Facebook/Bebo wanted to add to FOAF, for instance, “mood” they could add their NS “fb:mood” but is there a way to represent this in the JSON proposed?

Maybe the trick is really just to create some great libraries. SimpleXML for PHP has greatly increased the use of using XML. What if there was a “standards” extension with rendering backends.
$hcard = new StandardFormat::Factory(StandardFormat::hcard);

Developers balk at the verbosity of namespaces, they just seem so stuffy and academic. Programmatically they’re no more difficult to create, with some easy-to-use libraries.

Devil’s advocate signing off,
Dave

[...] The first Tydka-Bie is about the long forgotten FOAF functionality that Daddy-Cloud put into the system many moons ago. Incidentally, this particular entry is inspired by a post from David over on the echolibre blog. [...]

[...] may have read on this very blog a few months ago I wrote an article about having something called PJSF which basically is the concept or idea of defining a standard format for JSON feeds. When I saw [...]