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