Hi Florent,
I have some data in XML format with daily updates. I don't control this data, they come to me as XML, I don't want to convert them and make some mistakes, so I want to use a XML database. If I just add a <json/> element as root, I fix nothing about the string/integer conversion so I don't understand in what this is useful. And if XML only has strings there's no problem to go to JSON, they become strings in JSON !
While this might be true in your _specific_ case, it is not true in general. Even if you only have strings and don't care about numbers, other people do very much care about that. So we need to provide a mapping. Also the <json objects="json" /> element already adds mapping information, as it also could be <json arrays="json"/>. In the first case you get back an JSON object, in the latter one an array. How could we be able to determine that without any mapping information?
You will never be able to do a totally automatical lossless JSON<>XML conversion. However, you are able to write your own mapping functions which are useful for your specific use case
I have seen RestXQ which is probably excellent but it can't help me, because I just want a REST interface with JSON, so I can change my backend without frontend modificiation if needed.
I don't really get your argument here. RestXQ enables you to build a REST interface and you can in fact change your backend without any frontend modifications. In fact, it is much better at this job than the REST interface. As you already discovered, sometimes parameters in newer versions of BaseX change. Using REST you will have to update all REST calls in your frontend. Using RestXQ, you simply adopt your backend code. Also, you would not need all the format information in each and every REST call, as they would be defined in your backend RestXQ code.
I agree with you that the new options syntax for JSON output might be more verbose in this case. But it also gives much more flexibility and is much easier to handle especially in a RestXQ context and I am very happy we have this new syntax. Please also keep in mind that the majority of our users are using RestXQ rather than REST. As I already indicated I personally don't see many good reasons to use REST instead of RestXQ for application development. Hence, I very much doubt that we will switch back to the old method=jsonml syntax.
Cheers, Dirk
You will never be able to do a totally automatical lossless JSON<>XML conversion. However, you are able to write your own mapping functions which are useful for your specific use case
OK.
I don't really get your argument here. RestXQ enables you to build a REST interface and you can in fact change your backend without any frontend modifications. In fact, it is much better at this job than the REST interface. As you already discovered, sometimes parameters in newer versions of BaseX change. Using REST you will have to update all REST calls in your frontend. Using RestXQ, you simply adopt your backend code. Also, you would not need all the format information in each and every REST call, as they would be defined in your backend RestXQ code.
Yes, you're right. The problem is more that I'm afraid to be dependant (and to learn) yet an other technologie.
And if tomorrow the data given to me are no more XML, I will change my database and some URL in my client and it's OK. If I'm based on some other (great) techno, this could be more tougher.
But I will watch at it again, and if some few lines of RestXQ simplify my work, I will probably use it :-)
I agree with you that the new options syntax for JSON output might be more verbose in this case. But it also gives much more flexibility and is much easier to handle especially in a RestXQ context and I am very happy we have this new syntax. Please also keep in mind that the majority of our users are using RestXQ rather than REST. As I already indicated I personally don't see many good reasons to use REST instead of RestXQ for application development. Hence, I very much doubt that we will switch back to the old method=jsonml syntax.
I think that the back of method=jsonml as a shortcut or the default json set at jsonml instead of direct is a plus for new adopters, because this help to have easily something that work, and so stay with BaseX. I think that most of the non-JAVA non-XML people (as I am) just want that.
I was evaluating eXist first, they are doing easy JSON serialization for output: http://exist-db.org/exist/apps/wiki/blogs/eXist/JSONSerializer But as I don't found how to do it via REST, I switched to BaseX.
Do you have some informations about the performance penalty to do JSON conversion at the BaseX level ?
Cheers
Florent
Hi Florent,
Yes, you're right. The problem is more that I'm afraid to be dependant (and to learn) yet an other technologie.
true; of course there always is a learning curve. But we are commited to open technologies and RestXQ is an open standard and in fact it is also not that much complicated. In the end it is mainly a few annotations to server your XQueries at server side.
And if tomorrow the data given to me are no more XML, I will change my database and some URL in my client and it's OK. If I'm based on some other (great) techno, this could be more tougher.
That's true, but if you change your database technology in the future you will always have to make changes. If you just use a simply and easy RestXQ layer that won't be much. You would have the same if you have complicated REST calls, which you would have to rewrite. In the end you can use RestXQ not only as database layer, but as business logic as it is a full-fledged language. Of course, if you write lots of business logic than and in some time decide to not use it any more it will be a major effort to switch. But this also applies if you want to replace any other business logic language.
I think that the back of method=jsonml as a shortcut or the default json set at jsonml instead of direct is a plus for new adopters, because this help to have easily something that work, and so stay with BaseX. I think that most of the non-JAVA non-XML people (as I am) just want that.
I see your point. It is always a trade-off between simplicity for beginners and flexibility for experts. As JsonML is not our default JSON conversion algorithm I think it is ok to have a bit more difficult syntax.
Do you have some informations about the performance penalty to do JSON conversion at the BaseX level ?
I don't think we have a specific numbers on this at it heavily depends on your data. Simplest thing will probably to give it a try for your specific data set. In general I would say it should not be a major bottleneck. But of course if you want a super-fast JSON database there are more suitable solutions than BaseX.
Cheers, Dirk
Hi Florent,
Do you have some informations about the performance penalty to do JSON conversion at the BaseX level ?
I don't think we have a specific numbers on this at it heavily depends on your data. Simplest thing will probably to give it a try for your specific data set. In general I would say it should not be a major bottleneck.
I agree with Dirk; the conversion between XML and JSON is optimized pretty well and shouldn't cause any considerable overhead.
Cheers, Christian
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Dirk Kirsten -
Florent Gallaire