OASIS Approves OData 4.0 Standards For an Open, Programmable Web

First time accepted submitter Dilettant writes "The OASIS members approved Version 4 of the OData standards, which now also feature the long requested compact JSON as primary format. OData helps "simplifying data sharing across disparate applications in enterprise, cloud, and mobile devices" through interfacing data sources via a REST like interface."

Comments

JSON Sucks

[Jane Q. Public]

Look... I have to live with it in my work, okay? But it's anything but fun to work with.

For computer-to-computer data interchange, JSON is not bad. But it's about as human-readable as the Voynich Manuscript.

Re:JSON Sucks

[Anonymous Coward]

So it has pretty pictures then? Perfect!

Re:JSON Sucks

[pigiron]

You actually prefer XML???????

Re:JSON Sucks

[Anonymous Coward]

Using XML is like sticking your nuts in a vice and squeezing them until they burst. Although in the end it's still more pleasant than using XML.

Re:JSON Sucks

[Anonymous Coward]

Absolutely. XML is much more mature. XML has standardized schemas, validation, querying, transformation, a binary format and APIs for interoperability from any language. All JSON really has going for it is that it's already JavaScript.

The funny thing is that, at the end of the day, JSON and XML are the same thing, only syntactically different. Yet the prevailing opinion seems to be that XML is absolute and total shit whereas JSON is some golden calf.

Re:JSON Sucks

[Jane Q. Public]

I didn't say that. But since you asked:

IF the situation calls for HUMANS to read the data, I sure as hell do prefer XML. No contest. JSON is virtually unreadable.

Like I said: it's fine for computer data interchange, but when it comes to human intervention, give me XML any day.

I'm not claiming XML is perfect, by any stretch of the imagination. But when humans rather than computers need to deal with the data, it beats the shit out of JSON.

Re:JSON Sucks

[Jane Q. Public]

"The funny thing is that, at the end of the day, JSON and XML are the same thing, only syntactically different."

Yes, exactly. But XML is readable by people. JSON is not. Just try to read any big dataset in JSON, especially if it's minified. Good luck. At least with XML you have a shot.

Having said that: there are lots of good tools for converting from one to the other, so it could be a lot worse.

You make a good point about standards and validation, though, too. That's why business data interchanges are generally built on XML, and not JSON. Even though JSON is generally more efficient.

Re:JSON Sucks

[Desler]

How is JSON hard to read? It's just lists of key/value pairs

Re:JSON Sucks

[pigiron]

Really. Non of that totally unnecessary tag BS inherited from a printer definition spec (of all absurd things.) And key/value pairs are a hell of a lot easier to insert into a database in addition to being easier to read.

Re:JSON Sucks

[Anonymous Coward]

Yes, exactly. But XML is readable by people

No it isn't. Neither of them is. Not directly. They are *both* readable by humans with a good browser/editor. Tell the editor guys to get crackin' if they haven't already. When dealing with any format that's a hierarchy, you should be able to view the top level and click a little '+' or something to open it. Visual Studio even does that with C for cryin' out loud. Class graph browsers for C++ have been out for like... forever. I don't work with XML or JSON but I can't believe such editors are not available. If you try to edit them with Notepad, you get what you deserve.

Re:JSON Sucks

[Pascal Sartoretti]

XML is much more mature. XML has standardized schemas, validation, querying, transformation, a binary format and APIs for interoperability from any language.

Which means that XML will still be around in 10 years, and can safely be used today for major projects.

Re:JSON Sucks

[Anonymous Coward]

I'm baffled by this.
JSON and XML are about equally readable by humans.
For JSON with the white space removed, you'll want to "pretty-print" it to view... but it's the same for XML.

Re:JSON Sucks

[RightSaidFred99]

How so, specifically? I've never had an issue with it, but then I don't use bullshit scripting languages that force me to do lots of XML processing, let my tools do it for me.

So maybe you should rephrase - if you're using c. 1992 scripting languages, XML is total shit.

Re:JSON Sucks

[rsborg]

You actually prefer XML???????

Yes, as I deal in data interchange all the time, XML is great as it allows schema definition/sharing (XSD) and XSLT is a mature transformation language, that, after many years in the woods, is now available with functional capabilities (XSLT v3.0).

The only problem we have is that often, endpoint partners/vendors don't provide the XSD, nor do they share how they plan to validate files we send them. Or they ignore our XSD. But I still can't imagine things would be better if JSON were the interchange format.

If I control both endpoints (i.e., our browser script talking to our server through XHR), then JSON is an acceptable format. If not, I prefer XML.

Re:JSON Sucks

[Zaiff Urgulbunger]

Does JSON support namespaces? AFAIK it doesn't, and that would seem to make it suitable only for fairly simple data interchange and not really scalable.

As far as which is best visually... XML is a bit wordy/busy, especially if it uses a lot namespaces, but it's a pretty minor problem given that with both XML and JSON, it's a piece of piss to write a nice visual editor.

The important thing for me is having a solid platform for building applications, and XML has the capability and maturity for that - even if it is a bit ugly!

Re:JSON Sucks

[Zaiff Urgulbunger]

Does JSON support namespaces? AFAIK it doesn't, and that would seem to make it suitable only for fairly simple data interchange and not really scalable. As far as which is best visually... XML is a bit wordy/busy, especially if it uses a lot namespaces, but it's a pretty minor problem given that with both XML and JSON, it's a piece of piss to write a nice visual editor. The important thing for me is having a solid platform for building applications, and XML has the capability and maturity for that - even if it is a bit ugly!

I know it's bad-form replying to my own post, but it does appear that there is some kind of namespacing going on in the OData spec. Does anyone know if this namespacing is part of the JSON standard, or is it just a convention that OASIS are using?

Eitherway, I still prefer XML! :D

Re:JSON Sucks

[pem]

If the metric is readability without special tools, why stop there?

Neither JSON nor XML is easily writable without special tools.

YAML attempts to be writable, but the grammar and parser are huge and slow.

RSON is a superset of JSON that is eminently readable/writable, and much simpler than YAML, allowing, for example, for human-maintained configuration files.

The reference Python parser operates about as fast as the unaccelerated Python library pure JSON parser.

Re:JSON Sucks

[Jane Q. Public]

"Really. Non of that totally unnecessary tag BS inherited from a printer definition spec (of all absurd things.) And key/value pairs are a hell of a lot easier to insert into a database in addition to being easier to read."

Key-value pairs are a tiny subset of all data types. There are many data types that they have to struggle to represent very well. And when they try, the result (to the human eye) is a huge mess.

You're entitled to your opinion of course. But I think you're looking at it from a very narrow perspective. Have you ever actually had to program for the exchange of complex data sets? By that I mean something quite a bit more involved than a web store?

Re:JSON Sucks

[pigiron]

Yes. I'm lucky LISP can parse XML since they are really only just a special case of S-Expressions. Once out of that horrid mess of printer tags it was much more straightforward to validate them and insert them in all their complexity into a nicely normalized relational database.

Re:JSON Sucks

[Jane Q. Public]

"Neither JSON nor XML is easily writable without special tools. "

Sure they are. Take just about any object in Ruby and call [object].to_xml or [object].to_json.

More relevant to the discussion though, I think, is what someone else said above:

"XML has standardized schemas, validation, querying, transformation, a binary format and APIs for interoperability from any language. All JSON really has going for it is that it's already JavaScript."

I would have to say the same for RSON.

While it is true that they are syntactical versions of one another, XML is far less ambiguous. In a way, XML versus JSON is a lot like Java versus JavaScript. The former have more tightly defined specifications, and less ambiguity. (I.e., Java will not let you treat a string like an integer or vice versa.) Tighter specifications can be a PITA sometimes, but other times they'll save your butt. JSON, on the other hand, throws away information about the data that you will probably have to supply yourself later. Here's a very simple example:

Here is a picture of the same data represented both ways. (I would have just posted it here but Slashdot's bizarre character formatting will not allow.)

While it's true XML is a lot more verbose, there is no ambiguity. Take a look at the element labeled "created_at" (or "created-at" in the XML) for example. In JSON, it comes out as a string? WTF?

Not only do I argue that XML is a lot easier to read, you don't have to mess around with translating your data into different types when it you convert back. If I take that XML and convert it back to a Ruby object (one simple method call), I get the correct data types back. If I try to convert that JSON back to a Ruby object, I have to convert those dates (and other things if I had used a different example) back to the types they're supposed to be myself.

I should not have to do that. I am manually replacing information that JSON threw away. It requires that I build a special conversion routine for each kind of data set I am expecting to receive. Yuck. Why would I want to torture myself like that?

Re:JSON Sucks

[Jane Q. Public]

"No it isn't. Neither of them is. Not directly."

Yes, it is. If you don't believe me, I have posted a link to a simple example below. Not only is the JSON harder to read, it throws away data type information unnecessarily.

"When dealing with any format that's a hierarchy, you should be able to view the top level and click a little '+' or something to open it."

This is old stuff. TextMate (just for one example), has been doing that for a long time. Here's an example. Notice how the line numbers skip where the code is collapsed.

You can also open XML in Firefox, and again it does exactly the same thing: you can expand and collapse levels at will.

Re:JSON Sucks

[Jane Q. Public]

To what "scripting languages" do you refer? I do most of my work in Ruby, and dealing with XML is as simple as using the "to_xml" and "from_xml" methods on your data.

Re:JSON Sucks

[Jane Q. Public]

"Yes. I'm lucky LISP can parse XML since they are really only just a special case of S-Expressions. Once out of that horrid mess of printer tags it was much more straightforward to validate them and insert them in all their complexity into a nicely normalized relational database."

You are conflating XML and SGML. While technically XML is a subset of SGML, it doesn't contain "printer tags". It literally doesn't have any. XML tags are strictly data description.

Saying that XML is SGML is kind of like saying "car" is LISP. The former is a clearly-specified tool used for certain specific things. The latter is a generalized tool for many things. You wouldn't write an entire language like LISP to perform the function car performs. Nor would you write a specification like SGML (which does indeed contain printer tags) to perform the function that XML performs. One may be a subset of the other, but trying to say they're the same is just wrong. And weird.

Re:JSON Sucks

[Jane Q. Public]

Pardon me. I should have added that JSON is pretty much as easy: just use "to_json" and "from_json".

But the problem is -- as I mentioned in a post further up the page -- that JSON throws away some data type information. So when I use JSON, I have to reconstruct some of my data types when I use from_json. But I don't have to do that with XML.

And that's definitely a problem with JSON, not Ruby.

Re:JSON Sucks

[pigiron]

No it is not weird. XML is weird because it contains and is based on printer control cruft. Lots of printer control cruft. An unnecessary tag is a tag is a tag is a fucking tag.

Why do you think everybody hates it? Why do you think there are plans afoot (like the subject of this article) to get by without it?

XML sucks because it is based on a printer control spec. It's as simple and as ugly as that.

Re:JSON Sucks

[Jane Q. Public]

"No it is not weird. XML is weird because it contains and is based on printer control cruft. Lots of printer control cruft. An unnecessary tag is a tag is a tag is a fucking tag."

It does nothing of the sort. XML is a data description language. It's parent language -- SGML -- had a LOT of printer specification stuff in it. But XML has NONE. Not one little bit.

Jeez, guy. Pick up a book.

"An unnecessary tag is a tag is a tag is a fucking tag."

Then show me how to do the same thing without those tags that you call "unnecessary". Where are you going to get the information necessary to validate your data?

I linked to an example further up the page. XML preserved the data type, while JSON just turns any data it doesn't understand into a string. If I receive that data at the other end, and I don't already know what the data is supposed to contain, how do I know what that string represents? For all a program knows (unless you tell it ahead of time), it's somebody's fucking middle name, when it was actually supposed to be a timestamp.

They're useful for different things, as I originally stated. But there are A LOT of situations where JSON drops the ball when XML handles it with ease.

You can make a printer that uses XML for control. But XML, by itself, doesn't contain any "printer tags". Not one.

Re:JSON Sucks

[pigiron]

It's entire structure is *derived* from printer tags and most are useless. Apps that don't know what they are sending or receiving shouldn't be doing it in the first place. And in fact they don't. The whole semantic web concept is total BS and is in fact a total failure.

No b2b apps really need it as they are all custom built and the apps cloned from them already know the semantics of the data or they wouldn't have bothered to clone from them in the first place. XML is just added after the fact. It is useless cruft.

Why do you think everyone hates it? It's as bad as C++ which requires full knowledge of the application specific templates to be of any use. Kill them both.

Re:JSON Sucks

[Anonymous Coward]

It doesn't matter what it has. OASIS was taken over by Microsoft when they scuttled open document formats. They're still owned by Microsoft.

Why is anyone still paying attention to them?

Re:JSON Sucks

[Anonymous Coward]

What does XML have to do with the semantic web?

Re:JSON Sucks

[Anonymous Coward]

Don't worry, there's a good chance a lot of the people bemoaning the verbosity of XML have never had to use it. Things start to get hairy really quickly when you're trying to maintain multiple versions of a schema(s), and doing proper validation on each.

JSON is GREAT for basic configuration as an INI replacement, and passing serialized info between parts of your code (which is what I think a lot of the comments are really talking about). In turn, a lot of the weight of XML is there for good reason, and just because it isn't relevant to a particular application doesn't make it unnecessary.

Re:JSON Sucks

[RightSaidFred99]

Ruby is a scripting language, so it is included in the languages to which I refer. So yes, if that covers your use cases for XML then I agree doesn't sound very problematic so not sure why OP was complaining.

Re:JSON Sucks

[qtquocbao]

like á Ruby Thiên Nhiên

Re:JSON Sucks

[Anonymous Coward]

Absolutely. XML is much more mature

And has been from the beginning, right? LOL. We could as easily say it's much more old, or much more obsolete.

XML has standardized schemas, validation, querying, transformation, a binary format and APIs for interoperability from any language.

With JSON you don't need any of that. You have (simple!) parsers for all languages, and you can write validation, schemas and what not in the same language you use for your application, no need to use a dozen different notations.

at the end of the day, JSON and XML are the same thing, only syntactically different

So true. JSON is like XML, but without the chattiness, and much more convenient.

Re:JSON Sucks

[Zamphatta]

I couldn't agree with you more. I love XML far more than JSON. I don't get why so many seem to want to use JSON these days. Quite often, it's easy to glance at some XML and get an idea what to do with it, but you can't quite do that with JSON. Is there an XSLT equivalent for JSON? I haven't heard of one.

Re:JSON Sucks

[Jane Q. Public]

In a prior job I had to deal with large complex data sets in XML. The tools were not as good at the time, and dealing with such a large, complex set of data required a plugin ("gem") and some very involved data definition files.

But it's easier now.

Re:JSON Sucks

[Jane Q. Public]

Considering that "Semantic Web" standards deal with the use of tightly structured data, XML is a good fit and JSON just isn't.

XML has structures, standards, validation and flexibility that JSON sorely lacks. As someone else wrote above, the main thing JSON has going for it is that it's already JavaScript. Big deal.

I linked to a clear example further up. XML preserved my simple data structure. JSON threw away information about my data that I would have to supply myself later, if I were to use JSON to transfer that data. When working with structured data, that's a very bad thing.

The most common complaints I've heard about XML has been that it's "too verbose". Well, great. Try to come up with a standard for well-structured data that isn't. I'll wait.

Re:JSON Sucks

[pem]

I thought it was clear from the context that readability/writability meant BY A HUMAN, not BY A PROGRAM.

But I guess I suck at that myself, since we're obviously not communicating properly.

Obviously there are libraries in all sorts of languages to read/write both.

Yay!

[slashmydots]

If (PlatformIndepenentProgrammingRelated == True) And (RelatedToJava == False) {
Good!!!
}

They cracked the code on good web programming standards lol.

Re:Yay!

[danknight48]

If (PlatformIndepenentProgrammingRelated == True) And (RelatedToJava == False) {

Good!!!

}
They cracked the code on good web programming standards lol.

string message = "";
If (PlatformIndepenentProgrammingRelated &&
        !RelatedToJava)
{
      message = "Good!!";
}

Re:Yay!

[Anonymous Coward]

std::string message = PlatformIndepenentProgrammingRelated?RelatedToJava?""_s:"Good!"_s:""_s;

because I hate the guy who gets stuck maintaining things.

Re:Yay!

[Anonymous Coward]

Ok, you have types with leading lowercase letters, variables with both leading uppercase and lowercase letters, an "If" keyword with a captial "I" as in Microsoft BASIC, and you initialize a string unnecessarily. Please turn in your geek cred card. :-)

Re:Yay!

[ArhcAngel]

Ok, you have types with leading lowercase letters, variables with both leading uppercase and lowercase letters, an "If" keyword with a captial "I" as in Microsoft BASIC, and you initialize a string unnecessarily. Please turn in your geek cred card. :-)

He's logged in with a Google+ account. He never HAD one. In fact he actually likes beta!

Re:Yay!

[slashmydots]

You're missing something...the fact that I mixed 2 languages together to purposely make it not a real language.

Re:Yay!

[danknight48]

std::string message because I hate the guy who gets stuck maintaining things

Considering its the std:: c++ library, you should enable it correctly in stdafx.h for your whole project.
#include
using namespace std;

Re:Yay!

[danknight48]

Ok, you have types with leading lowercase letters, variables with both leading uppercase and lowercase letters. with a captial "I"

Copy and paste for the win.

and you initialize a string unnecessarily.

Necessarily, i initialize the string correctly and give it a NULL value, before i go ahead and play with it.
I'd love to see the values of your variables. Wonder how many of them are uninitialized and causing havoc in your code.

O'Data

[Megahard]

An Irish android? How appropriate!

I'm not clear....

[MightyMartian]

I'm not clear here, isn't that the purpose of TCP/IP?

Re:I'm not clear....

[silas_moeckel]

TCP is for reliable in order transmission/reception of octects.

Re:I'm not clear....

[Guy Harris]

TCP is for reliable in order transmission/reception of octects.

...and standardizes nothing about the content of those octets, so, as you suggest, TCP, by itself, is insufficient to "[simplify] data sharing across disparate applications in enterprise, cloud, and mobile devices".

Oh the irony

[OzPeter]

At the link for the specifications OData JSON Format Version 4.0

The documents that are tagged as Authoritative are .doc, not even .docx

Re:Oh the irony

[Anonymous Coward]

Oh the irony

History, not irony.

Microsoft took over OASIS in 2006 as part of their campaign to scuttle open document formats. They're still running the show there.

http://www.zdnet.com/microsoft...

what?

[Anonymous Coward]

What do those whiny bastards have to do with programming standards???

Keep to music, you assholes.

Reinvention of RDF + SPARQL

[nickmalthus]

Glancing over the specification it looks like a reincarnation of RDF plus SPARQL for updates. Perhaps a product of Not Invented Here syndrome? I am sure it will end up like most OASIS standards: developed in a bubble by company insiders, introduced as selling points in the next versions of said companies products, rejected by the marketplace due to complexity and lack of adoption, and then ultimately discarded in favor of the next technology fad that purportedly better solves the problem space.

Re:Reinvention of RDF + SPARQL

[bmajik]

SPARQL appears to be read only, and to be restricted to data in kvp or 3-tuples.

OData supports mutable entities, change and request batching, and http GET semantics for data access. It would appear to map much better to real-world databases and business use-cases.

Re:Reinvention of RDF + SPARQL

[RightSaidFred99]

OData has been around for ages, it's not new. It's a standard for passing rich, structured queries over HTTP, that's it.

Re:Reinvention of RDF + SPARQL

[nickmalthus]

SPARQL 1.1 supports updates (insert/delete) and the SPARQL CONSTRUCT operator can be used to build query results in a nested graph format. Additionally SPARQL protocol defines a standard HTTP binding protocol that can generate output in CSV and JSON formats in addition to XML. To me it appears OData is a reimagining of W3C's Semantic Web efforts.

Re:Reinvention of RDF + SPARQL

[bmajik]

You could be right.

OData predates SPARQL 1.1, however, and supported all CRUD operations from its inception.

What is OData? Why should you care?

[bmajik]

OData is (now) a standard for how applications can exchange structured data, oriented towards HTTP and statelessness.

OData consumers and producers are language and platform neutral.

In contrast to something like a REST service, for which clients must be specifically authored and the discovery process is done by humans reading an API doc, ODATA specifies a URI convention and a $metadata format that means OData resources are accessed in a uniform way, and that OData endpoints can have their shape/semantics programmatically discovered.

So for instance, if you have entity named Customer hosted on http://foo.com/myOdataFeed, I can issue an HTTP call like this:

GET http://foo.com/myODataFeed/Cus...

and get your customers.

furthermore, the metadata document describing your customer type will live at

foo.com/myODataFeed/$metadata ... which means I can attach to it with a tool and generate proxy code, if I like. It makes it easy to build a generic OData explorer type tool, or for programs like Excel and BI tools to understand what your data exposes.

Suppose that your Customers have have an integer primary key, (which I discovered from reading $metadata), and have a 1:N association to an ORders entity. I can therefore write this query:

GET http://foo.com/myODataFeed/Cus... .. and get back the Orders for just customer ID:1

I can add additional operators to the query string, like $filter or $sort, and data-optimization operators like $expand or $select.

OData allows an arbitrary web service to mimic many of the semantics of a real database, in a technology neutral way, and critically, in a way that is uniform for anonymous callers and programmatically rigorous/discoverable.

Examples of OData v3 content are available here:

http://services.odata.org/V3/N...

OData V4 is a breaking protocol change from V3 and prior versions, but has been accepted as a standard

And, shameless plug: If you want to consume and build OData V1/V2/V3 services easily, check out Visual Studio LightSwitch :)

Microsoft.

[RightSaidFred99]

Know who leads the OData brigade? Microsoft. Get your crying ready, neckbeards.

On a more serious note, OData is awesome. If you've ever tried to provide a good data query API (supporting boolean syntax arbitrary queries) via a web service it's not easy. OData does it very well.

Sure, you'll get some whining from people who don't understand it that it forces you to expose your data model to the outside world, but it does absolutely no such thing. You can, should you choose, expose a complete abstraction layer over your data model. But for a lot of uses it's really easiest to just let Visual Studio do its magic an presto, you have a web service accessible data access layer.

Re:Microsoft.

[Anonymous Coward]

Yeah, its odd. They described it well, people have made libraries for it in many languages. I advocate for it.

But what do you think happened at Microsoft? Either:
a) they randomly happened to make something useful and worthwhile, showing that eventually the monkeys/typewriters thing
or
b) someone managed to get it out before management knew it, or they would have killed or ruined it.

Re:Microsoft.

[RightSaidFred99]

Lol.. The only problem with your attempt at being snide is that Microsoft's development technologies, whatever you think of their desktop OS, phones, or office suites, are beyond reproach so your joke falls more than a little flat.

Sold!!!

[Giblet535]

I saw that it's embraced by Blackberry... Nice name-drop! I'm in!

REST buzzword

[bug1]

Representational state transfer (REST) is an architectural style consisting of a coordinated set of architectural constraints applied to components, connectors, and data elements, within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements

- from wikipedia

its a framework ?

Re:What is OData? Why should you care?

[CODiNE]

Sounds neat but doesn't solve my JSON problems.

One project might use "customer" another "client" or "businessname". Each of these may have a "description", "overview", "synopsis" and a "type"/"kind"/"businesstype" field.

So code discovery of data doesn't work unless we have agreed to standardized field names in advance, but now there's always exceptions to look out for and name conflicts.

Now even if we know the names of every field, how do we know exactly what sort of data will be returned? A name alone is nothing unless we can ensure its type, and remove all assumptions about what it can contain.

JSOAP?

[R3d Jack]

This is sound eerily familiar...

Re:What is OData? Why should you care?

[bmajik]

I suggest you look at the $metadata document for the service I linked to.

The property names, conceptual storage types, relationship info, etc, is all in there.

I'm not sure what problem you're trying to solve, exactly.

Then use XML

[benjymouse]

One project might use "customer" another "client" or "businessname". Each of these may have a "description", "overview", "synopsis" and a "type"/"kind"/"businesstype" field.

So code discovery of data doesn't work unless we have agreed to standardized field names in advance

Why doesn't it work? Have a look at $metadata. You get schemas for your data. OData has full discovery. The only "standardized field name" you need to know in advance is $metadata.

... but now there's always exceptions to look out for and name conflicts.

Now even if we know the names of every field, how do we know exactly what sort of data will be returned? A name alone is nothing unless we can ensure its type, and remove all assumptions about what it can contain.

OData was originally designed for XML. JSON was added later. With XML you can (and should) use namespaces to disambiguate field names between different entities/domains.