 I'm Jonathan Roby, I work at EMC Corporation. I'm a rest architect and a courier architect. I'm going to be giving a talk about JSONIC. How many people here know what JSONIC is? OK. There are places you can go and not get that percentage of the group knowing. JSONIC is developed by team of people who come from different companies. I work for EMC Corporation. There's several people here from 28 MSEC. There's Dana, who works for Oracle, and is also somehow associated with 28 MSEC. A lot of the work was funded with help from the Flower Foundation, which is an xQuery advocacy group. JSONIC is a line which is not a product or a company. I'm not trying to sell you anything. If you are a NoSQL database vendor, I'd like to see you sell stuff using JSONIC. And 28 MSEC has something to sell you. I don't get any money out of that. We're under NoSQL conference. And for a lot of database people, the first question you ask is, what do I use to create the database? Well, what do you use to create NoSQL database? I've heard three answers as a walk-on conference. The first is, well, not SQL. The second is, which database? And if you go talk to the vendor, they say, well, we have this query language that we're using now. But we're also considering doing something else. So we'll have another one later. And I also hear the answer, well, we're still young technology. You don't need to know the answer to how to query a database just yet. We'll get there eventually. For a lot of database people, this is very odd. One of the fundamental things you need from a database is the ability to query it. Now, it's not because there aren't query languages for JSON. There's lots of them. For traditional queries, the kind of thing where you write a query, you get an answer back immediately. We have Mongo query language. That's a template-based query language. We have Uncle, which is a SQL-based language. Does anybody know the status of Uncle? Is that actually going anywhere at this point? Is there anybody else here from Coach? Well, I was written by Damian Katz. And it got tiled because they had a couple of other hyperties. And they were very interested in JSONic as their next iteration. Oh, cool. I like that answer. A lot about from Coachbase, which we'd just like to talk to you after a little time. OK, cool. There's a bunch of Dataflow languages. These are for huge amounts of data. And they do something fairly different. If you go, for instance, the PIG site, it'll say, don't use this as a regular query language. And Jack will tell you the same thing. It's for data warehousing applications where turnaround time on query isn't what's important. It's the overall time of processing the results. There's nothing widely accepted for a traditional query. Mongo looks kind of like this. It's template-based. And when we looked at this, this isn't really a good starting point for a general purpose language because the templates aren't easily combined if you pull a composition, OK? If you want to talk to me about that afterwards, I can explain more in depth. I have to go purely quickly with this slide because I want time for questions, too. This is a SQL-based language. One of the problems with using SQL as a starting point is SQL was designed from query tables in order to get tables. And when we, on the xQuery working group, started trying to expand SQL to come up with something to query trees and come up with trees, we found that it was very difficult to do that well. That if you wanted it to be fully general, you ran into various problems. And they're fairly subtle problems. But we spent a long time fighting it out with use cases. There was a very strong contingent who wanted to do just exactly that for xQuery. And they lost because there were things that it didn't do well. The data flow languages, I think some of these languages are quite nice. Pig Latin is fun. They have amusing documentation. Somebody has a good sense of humor on that site. HiveQL is a SQL-based data flow language. It runs into some of the same problems that you get anytime you try to use a table-based language for trees. Elegant, as far as it goes. General is a very nice functional language. I really like the design of this. But it's not what I want to use for xQuery. It's not designed for that. The XML world is fairly different. There is one query language that has become the language that's dominant for XML queries. It's designed for tree structure data. It's been implemented in many different environments. I used to work for data-direct technologies. All of our xqueries were translated into SQL xqueries against relational databases, any relational database. You can do joints across them, that sort of stuff. We were part of the process. We had another xquery implementation that worked in a messaging environment. I worked at Red Hat and did some xquery-based message routing when I was there. Donna worked at BEA, where they were doing large streams, XML and large streams of data. xquery has been implemented in a wide variety of very different environments, which is kind of nice for no SQL, because no SQL is implemented in a very wide variety of environments. And xquery is designed for tree structured data. It knows how to work with trees. Well, could we have an xquery for JSON? What would that look like? Well, one thing you might want is to get rid of XML altogether. So JSON gets two profiles. One of them gets rid of XML. If it has an angle bracket, kill it. That means you get rid of namespaces, having to worry about elements versus attributes, and naming every time. Everything, when you create a result, document order, XML schema, XML navigation, all that complexity goes out the window. And that's a huge percent of the complexity of xquery. The most complex thing about xquery is XML. Xtap navigation is much more complex than what you need for JSON. We add in JSON objects and arrays. That's the only complex data structure you need. And you keep the expressions for tree and tree structured data. We have another profile that has both XML and JSON. Now, that's no longer path-free. You have XML. But it's not that much matter in the next query to start with. Can I have a show of hands? How many people here need to process XML and JSON? How many people here are pure JSON environments? So I hear JSON purists telling me they wish they could do just JSON. But I mostly hear people say they have to do XML too. And one of the nice things about xquery was it was designed as a data integration language for more than one kind of data. Some of the languages helped inform it. The languages like Yackle, for instance, or the original Uncle, that were languages for operating on views of different things to create concrete results. And that's one of the reasons that it can be implemented in so many different environments. So here you have the complexity of XML. But you also have the poor guy that speaks that language. Xquery makes things like XML much easier to deal with than trying to figure out in something like Python. The same expressions can be used for JSON, XML, or HTML. If you're using HTML5, you need an HTML compiler to translate a data into something that's well-formed first. By doing that, either with or without the XML, you get a declarative functional language that has a native XML data model, or now this is xquery functionality, or a native JSON data model. It's designed for data integration. You have queries and transforms. You have joins, grouping, windowing, updates, full text, functions, and libraries. You can subset that. If you're a vendor and you don't want to implement it all, fine. We don't get to have performative profiles if we get to the point that this is really standardized. We may want to do something like that. Let's look at the language in a nutshell. The first thing we have is object and array constructors. This looks like JSON text. It's also a JSON expression. Guess what it does? It creates an object that object has an array in it. But it creates the data model representation of it. OK? We have member accessors. So let me bind this to the variable 0. I can ask for Sarah's friends. Well, there's an array here. I can ask for the first one of her friends. You don't need x.com. You can just use very simple accessors and chain them. We have object unions. It turns out that, frequently, when you're working with JSON, what you're doing is you're taking objects, and you're combining them. You want the members of this object plus the members of that object. So here I have height 5.2, eyes of blue, kuchikuchikuchiku, and you do an object union, and it has the pairs from each. OK? And here's what's actually the most important feature of JSONic. This is the feature that allows you to not add all kinds of other features, like x creates compositional. And what I mean by that is, if you point to something in an existing literal JSON structure, I can replace it with an expression. So here I have the expression Sarah's friends. You see, in this query, I find Sarah, and then I create a new person named Amanda. And Amanda's one year older than Sarah. Here's one expression. And her friends are the same friends as Sarah's friends. OK? I probably should have added Sarah to that. Presumably, Sarah's also friend here. And I can do the same thing over here. I can create the keys in the same way using expressions. Now, you can do two things here. You can point to anything in any JSON object anywhere. And you can create any JSON structure and multiple structures. And you can create any part of it using expressions. That's the most important feature here. It's a flexible grammar, basically, a flexible, well-structured grammar. Let me give you an example of something you can do in JSON. Like, here's a group. I've got a bunch of products that are being sold. So a broiler in store number one. I sell plenty of these. I have some kind of warehouse or something like that. And I'm getting the feed of sales that happen. What I want to do is I want to group my sales by product across stores. Here's my object union. So I'm going to create a bunch of objects in here. One represent each group. And what I do is I go through my sales collection. And I get my product name. I'm going to group by the product name. And then I'm going to return the product name and the quantity for each one. Standard group by query a lot like is equal group by. And here's the result. Now, if you've really drunk some of the NoSQL Kool-Aid, and we have heard people say things like, don't do joins. Don't do group by. It might require the database to do work. And that will slow everything down. You don't have to do this in the database engine itself. You can do this in a variety of places in the architecture. You could do this in the client driver. You could do all the calls off the database to do your grouping there. That's just as efficient or as inefficient as doing it with the NoSQL database that can't do grouping. You could do that on the middle here so that you could have a tier that does the combinations like grouping provided by the vendor that would take the load off the individual databases but would still be local, network local to where the databases are. You could push this into the database. And you can look at the performance trade-offs. You could imagine a vendor saying that it's configurable where this join is actually done. These trade-offs have to be, these are inherent trade-offs. You will not get better performance by telling somebody they have to do it in their program. You're just being harder for the person to write the program. So in other words, saying declarative is good. It allows you to optimize things. Let's make a more complex query. Now I've got also products with product names and stores, and I want to group on my products and on my stores. Okay, these aren't incoming things. These are more stable tables that will help me know how to group things. So here's a query. I'm going to group by state, by category, and by product name, and I'm going to sum within that. And here's the result of my query. That's code you didn't have to write. Another very standard thing that you're going to do with JSON is mediate between the XML world and the HTML world. So you're looking at some universe of HTML, XML, and JSON. You go out, you query all that stuff. You create the result. You can create that result in HTML or XML or JSON. Here's an example. I just took a dump from Wikipedia on Origami. I don't know anything about Origami, but you have to do something that's politically neutral. So I chose Origami. I like Origami. Down here, I have a query. This is an actual file in my hard disk right now. And what I do is I look at the individual pages, and for each page I create an object. And that's going to have a title, an ID, the last up-pated, and the authors. And I'm pulling it straight from here. That's not a very complex query at all. And here's the result. Another really interesting use case for me is views of relational data. I should tell you that at one of the companies that worked for data-direct technologies, my main product was something that was basically a JDC driver that could view any relational database as though it were XML. And that's been used by some people who are doing things where they're actually creating web pages or creating XML documents or things like that. Well, that's a lot. And the SQL committee actually came up with a standard for what relational data looks like in XML. So there are people that are very interested in this. It turns out that JSON is much more a path-free way of doing a representation of relational data. It doesn't add all kinds of namespaces and stuff that aren't really part of the relational data model. This is much closer to the original data. Okay. And I intentionally left a lot of time for discussion here. I hope I didn't talk too quickly on these slides, but now what? Well, if you're a user, I have to warn you that JSON is still a ballroom. We've gotten this to where we've gotten sort of... It's been implemented at least once. We're playing around with it. We've found a couple of things that we want to improve. We're trying to submit this to the xQuery working group. We'll see how much of that they take up. We're trying to engage with vendors. We'd like there to be a query language for no SQL databases, because creating a database is important. And this is something where vendors get involved with us. We definitely will take your needs into consideration and find fair ways to figure out how to do the negotiation and things like that. You can go here to find the current stage of the specification and use cases. You can find a demo here. Instantly, there's going to be another conch at 1145 by Chris Hillary. Let me see if I can... On the JSONIC site, you can find the specification per se in PDF or HTML, whatever. You can also find the grammar, railroad diagrams, if you're interested in that sort of thing. Now, where did my... Excuse me. Thank you. And there's a demo, a live demo that you can find. This is a 28 Msec people's implementation. So you can come here and you can welcome JSONIC and you can just pick a query and execute it. You can type your own queries in here so you can say you'd rather have some or something like that. This is live. It actually works. So you can play with that. I don't work with 28 Msec. I believe they have a version you can download. Yeah, so this is one developer. So it's open source. I've actually used a license. Okay, so it's an open source, Apache 2 license, and you can download it, play with the source, things like that. Now let's open up to the discussion. Yes. I was wondering if you guys had any thoughts on hierarchical roll-up or even cube for that matter in this space? Okay, I'm not big on analytics. This is not something that I'm real informed on. Here are two things that I know that we have. We have windowing and we have higher order functions. And my guess is that you might be able to roll a lot of things that would interest you using those two things. But somebody who actually knows what he's talking about would be better to answer that particular question. Yes. I'd just like to get your feedback on the strategic nature of this as far as the NoSQL movement becoming a NoSQL platform on an application developer. And we've developed applications that run on native XML databases like this. We know we can port them to Zorba and to Basex and to MarketLogic. So I have four platforms that I could run on. But only about 80% of the data that I have is really based on the other 20% of it's mixed content in any of these spaces. But I would very much like to be able to run my applications on couch-based and I would give a lot of my customers a lot of options for running open source scale systems. Is it possible that this could run on those systems? Sure, did everybody hear that question first off? Let me tell you, 20 Demsec already runs on top of Mongo. And as I understand it, it takes the X-query expressions and it pushes the conditions down. You know what I mean by pushing select through a join and that sort of stuff. So it already does that kind of optimization on Mongo. And I don't know, is anything planned with couch at this point with 20 Demsec? We've talked to them and they're very interested in looking into the JSON express application. Because as you said, they are looking into a query language and they obviously see the benefits and they're looking into it. Yeah, so I don't speak for any other vendor than EMC and I haven't asked EMC what I can say here. So I can't say anything concrete about this, but I think if Mongo and college, for instance, if just those two companies would take up something like this, I think it'd be great for the NoSQL community. That's up to them, that's not up to me. I agree, NoSQL is failing to become a platform because anytime I write anything for NoSQL, I am completely tied to that one platform. And the purism of NoSQL on saying that I can't do XML2 hurts me because in my world, JSON is a lot of what I have to do, but it's not all of what I have to do. So I would love to see this widely implemented. That's actually a lot of my, I'm kind of an idealist. That's why I'm putting everything into this. Any other questions? As a follow on question, does it make sense that application developers would want portability to the process? Are there any other people that are developing applications that they'd like to run across NoSQL platforms? How many people here are application developers? How many of you want something like this? Okay, that looks like an answer. Yes? I'm not a developer, I'm an architect, an information architect, and I do want to ask you, what can we do to persuade all the vendors to adopt it? Because this is great, this is the thing that NoSQL movement lacks. I'd like to give you an answer to that. Don't talk to them, just put a piece of open source in there. That's it. That's how it goes. That could be done by third parties. Sure, it could be done by third parties. Because the portability, the idea of portability, the idea of merging between JSON world and XML world and SQL world, that's the greatest idea, right? That's where the strength is, I think. So here's something that I feel strongly about. Vendors are worried about other vendors, right? There are curve force here. And in the XML community, it was very clear that we would have meetings and it would be IBM and Oracle and Microsoft and then whatever little company I was working for at the time. And we'd be duking it out, because what we had to come up with was a fair process where it was clear that this is not the advantage of any particular vendor. And one of my hopes is that JSON can be a clear, that we're transparent. If you look at the people who are doing this, I mean, okay. The Flower Foundation is nothing that's commercial. 28Msec is a commercial company, but it doesn't actually have an OSQL database. I think Don found out that Oracle's doing an OSQL database, but this wasn't being done for that purpose. EMC has a variety of databases, but we're not trying to, none of us is trying to be a monopoly here and none of us will be happy if it's not a fair process. Yes. To be fair, I've been in XML standards development myself for five years, 10 years after I learned about XML. So I'd say the life cycle in XML is quite mature really, both into this stuff. And you could probably expect more pole lessons. X-query language is a standards dialogue, but it has been from the day it was started. But it took eight years. It's not like it was said. Oh, absolutely. Absolutely, but what we're trying to do with JSON, is have a good starting point. And one of the things that, some of us are standards, what do you call it? Standards of veterans, you know, you have bullet holes in us. All they are is home-backed proof. Yeah. I think one of the things that the JSON community lacks, I think the JSON community lacks two things, community and a sense of building something for the greater good across individual vendors. And I would like to see users demand that. I would like to see users say, we really need this kind of stuff. And you know, I don't care if JSON changes. You know, I'm sure that there are requirements that we don't know yet. I'm sure that there's a better way to do this or that in the language. But for NoSQL to be really useful for me personally, I need something I can use with more than one database. And it needs to work with more than just JSON. All the NoSQL things are nice now for what you've built. We've talked about it before for specific database, but just imagine the power of being, developing for Mongo and saying, okay, now I wanna try it on Couch. And then, okay, now let's try it on this other one. You don't have to rewrite your application. You can just slide in and remember it as equal database. That's pretty proud of it. Yeah, absolutely. Okay, so I guess you get what this is about. At 11.45, there's going to be a talk on how to implement this. There is one open source implementation of JSON out there you need to use at its basis. There's a lot of open source implementations of XQuery if you want. One that fits your particular implementation environment. I'm here to talk to, Donna back there is here to talk to. Please, vendors get in touch with us. Please, users, put pressure on your vendors to get in touch with us. Thanks.