Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
Hello Marco,
I don't really get why you want to exclude languages which you call "lower level of abstraction", at least to me the architectural reasons are not obvious at all. In the wild when I see XML handling applications which are not XQuery/XSLT I would say they are mostly Java, C# or python applications. All of them have XML handling capabilities, although I think they are rather weak and limited if you know XQuery. Bu anyway, certainly many people are using these languages for data handling in general, so I think they are a valid choice.
Apart from that I think there is not so much to compare XQuery with. Jsoniq comes to mind, because it is based on XQuery, but I think it is probably dead and never got any traction.
And depending on the scale of the data processing you handle you might want to consider a map/reduce approach, e.g. by using Hadoop and one of the several languages specifically designed for it.
Just my thoughts. Hope it helps
Dirk
On 02/22/2017 04:13 PM, Marco Lettere wrote:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
Hi Marco,
Just like you, I fell in love with XQuery and BaseX several years ago.
I had the opportunity to put BaseX into production twice. Each time, it was live in production before the team had started wondering how to architecture the whole thing in a J2EE way.
And each time, for political reasons, the XQuery solution was eventually replaced with a J2EE one.
IMHO because CTOs never like to see their tooling decisions challenged, and mainstream software engineers cannot imagine there could be an alternative to the TDD/J2EE/imperative language solution, when they are not simply thrilled by the elegance and power of XQuery/REST-XQ.
Maybe a solution could be to directly speak to business oriented people, that will appreciate how fast you can provide them with solutions.
A JSON promising solution might be the N1QL language upon Couchbase.
Best regards, Fabrice Etanchaud
-----Message d'origine----- De : basex-talk-bounces@mailman.uni-konstanz.de [mailto:basex-talk-bounces@mailman.uni-konstanz.de] De la part de Marco Lettere Envoyé : mercredi 22 février 2017 13:43 À : BaseX basex-talk@mailman.uni-konstanz.de Objet : [basex-talk] Somewhat unusual question
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
Hello Marco and all,
There was a similar question asked on the xquery-talk mailing list two years ago: "what are the prime factors behind the resistance to adopt XQuery or it's derivatives". Here's a direct link to that thread [1].
Around the same time there was many similar topics about other competing technologies that kind of were easier to sell for business people, but from a technological point of view was/is just plain stupid. You might want to look around in the threads of june 2015 [2].
[1]: http://x-query.com/pipermail/talk/2015-June/004783.html
[2]: http://x-query.com/pipermail/talk/2015-June/thread.html
Cheers Kristian K
22.02.2017 14:43 Marco Lettere kirjutas:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
What the application is makes all the difference. If the purpose does not have to do with XML and XML in a database, then XQuery and BaseX is less likely to be appropriate.
Kendall
On 2/23/17, 12:36 PM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Maximilian Gärber" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of mgaerber@arcor.de> wrote:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com: > Hi to everyone, > > probably this is not the right place for such a discussion but the BaseX > communitiy is the one I'm better introduced to and the one I trust the most. > So I hope that this somewhat unusual excursus will anyway be of interest to > some of you. > > As for myself I fell in love with XQuery and its power in terms of data > manipulation many years ago. I wouldn't change it with anything else and BTW > we're using it (thanks to the incredible BaseX runtime) much beyond > data-processing being it the backbone of all our micro-service oriented > architectures. > > Now, to the point, in the near future I probably will be called to face a > somewhat skeptical customer who will argue about the technological choice of > XQuery. > > My point will be to make a comparison with the technologies they're > currently using and I would like to demonstrate that for a rather XML- (and > in general data-) intensive workflow XQuery is perfectly suitable and > probably better than many other alternatives. > > I would tend to exclude XSLT because it would face similar opposition. I > would also exclude languages at a lower level of abstraction like Java, > Python, Javascript, C/C++ and so on for obvious architectural reasons. > > But then only templating languages/engines come to my mind. Those would > still be probably novel technologies to learn and wouldn't offer the > structural, syntactic and semantic power of XQuery anyway. > > So I ask you kindly, in order to complete my preparation on these matters, > is there anyone that has experience with other tools or languages that can > be compared with XQuery when used for XML querying, generation, > transformation, templating, composition and so on? > > Thanks a lot! > > Marco. >
Hi Kendall,
I do not agree. A few considerations. If data are XML, I find it difficult to use a different language from XQuery. It is possible, of course, but much much more complex (why doing that?!). But native XML files are not the entire story. You can transform, for example, all of text data into an elegant XML working version and very very easily query it. I can do whatever I want with XQuery easily and deal with different kinds of data, so I do not agree at all.
Il giorno 24 feb 2017, alle ore 00:37, Kendall Shaw kendall.shaw@workday.com ha scritto:
What the application is makes all the difference. If the purpose does not have to do with XML and XML in a database, then XQuery and BaseX is less likely to be appropriate.
Kendall
On 2/23/17, 12:36 PM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Maximilian Gärber" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of mgaerber@arcor.de> wrote:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
For example, a program that regulates flow of water in a garden sprinkler is probably not a good match for xquery and an xml database.
On 2/24/17, 2:20 AM, "meumapple" meumapple@gmail.com wrote:
Hi Kendall,
I do not agree. A few considerations. If data are XML, I find it difficult to use a different language from XQuery. It is possible, of course, but much much more complex (why doing that?!). But native XML files are not the entire story. You can transform, for example, all of text data into an elegant XML working version and very very easily query it. I can do whatever I want with XQuery easily and deal with different kinds of data, so I do not agree at all.
Il giorno 24 feb 2017, alle ore 00:37, Kendall Shaw kendall.shaw@workday.com ha scritto:
What the application is makes all the difference. If the purpose does not have to do with XML and XML in a database, then XQuery and BaseX is less likely to be appropriate.
Kendall
On 2/23/17, 12:36 PM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Maximilian Gärber" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of mgaerber@arcor.de> wrote:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com: > Hi to everyone, > > probably this is not the right place for such a discussion but the BaseX > communitiy is the one I'm better introduced to and the one I trust the most. > So I hope that this somewhat unusual excursus will anyway be of interest to > some of you. > > As for myself I fell in love with XQuery and its power in terms of data > manipulation many years ago. I wouldn't change it with anything else and BTW > we're using it (thanks to the incredible BaseX runtime) much beyond > data-processing being it the backbone of all our micro-service oriented > architectures. > > Now, to the point, in the near future I probably will be called to face a > somewhat skeptical customer who will argue about the technological choice of > XQuery. > > My point will be to make a comparison with the technologies they're > currently using and I would like to demonstrate that for a rather XML- (and > in general data-) intensive workflow XQuery is perfectly suitable and > probably better than many other alternatives. > > I would tend to exclude XSLT because it would face similar opposition. I > would also exclude languages at a lower level of abstraction like Java, > Python, Javascript, C/C++ and so on for obvious architectural reasons. > > But then only templating languages/engines come to my mind. Those would > still be probably novel technologies to learn and wouldn't offer the > structural, syntactic and semantic power of XQuery anyway. > > So I ask you kindly, in order to complete my preparation on these matters, > is there anyone that has experience with other tools or languages that can > be compared with XQuery when used for XML querying, generation, > transformation, templating, composition and so on? > > Thanks a lot! > > Marco.
A more interesting example, maybe: If you compare XPath with this SPARQL fragment:
?x foaf:knows/foaf:name ?name .
All of my friend’s friend’s friend’s friend’s friend’s etc., with arbitrary depth, who know my friend with name x.
Friends are not limited to having 1 “befriender” in the way that elements have 1 parent, so it could make sense to represent some data as a less restricted form of graph than an XML element tree.
Kendall
On 2/24/17, 10:07 AM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Kendall Shaw" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of kendall.shaw@workday.com> wrote:
For example, a program that regulates flow of water in a garden sprinkler is probably not a good match for xquery and an xml database.
On 2/24/17, 2:20 AM, "meumapple" meumapple@gmail.com wrote:
Hi Kendall,
I do not agree. A few considerations. If data are XML, I find it difficult to use a different language from XQuery. It is possible, of course, but much much more complex (why doing that?!). But native XML files are not the entire story. You can transform, for example, all of text data into an elegant XML working version and very very easily query it. I can do whatever I want with XQuery easily and deal with different kinds of data, so I do not agree at all.
Il giorno 24 feb 2017, alle ore 00:37, Kendall Shaw kendall.shaw@workday.com ha scritto:
What the application is makes all the difference. If the purpose does not have to do with XML and XML in a database, then XQuery and BaseX is less likely to be appropriate.
Kendall
On 2/23/17, 12:36 PM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Maximilian Gärber" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of mgaerber@arcor.de> wrote:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com: > Hi to everyone, > > probably this is not the right place for such a discussion but the BaseX > communitiy is the one I'm better introduced to and the one I trust the most. > So I hope that this somewhat unusual excursus will anyway be of interest to > some of you. > > As for myself I fell in love with XQuery and its power in terms of data > manipulation many years ago. I wouldn't change it with anything else and BTW > we're using it (thanks to the incredible BaseX runtime) much beyond > data-processing being it the backbone of all our micro-service oriented > architectures. > > Now, to the point, in the near future I probably will be called to face a > somewhat skeptical customer who will argue about the technological choice of > XQuery. > > My point will be to make a comparison with the technologies they're > currently using and I would like to demonstrate that for a rather XML- (and > in general data-) intensive workflow XQuery is perfectly suitable and > probably better than many other alternatives. > > I would tend to exclude XSLT because it would face similar opposition. I > would also exclude languages at a lower level of abstraction like Java, > Python, Javascript, C/C++ and so on for obvious architectural reasons. > > But then only templating languages/engines come to my mind. Those would > still be probably novel technologies to learn and wouldn't offer the > structural, syntactic and semantic power of XQuery anyway. > > So I ask you kindly, in order to complete my preparation on these matters, > is there anyone that has experience with other tools or languages that can > be compared with XQuery when used for XML querying, generation, > transformation, templating, composition and so on? > > Thanks a lot! > > Marco.
I do not think this an argument to
Il giorno 25 feb 2017, alle ore 00:05, Kendall Shaw kendall.shaw@workday.com ha scritto:
A more interesting example, maybe: If you compare XPath with this SPARQL fragment:
?x foaf:knows/foaf:name ?name .
All of my friend’s friend’s friend’s friend’s friend’s etc., with arbitrary depth, who know my friend with name x.
Friends are not limited to having 1 “befriender” in the way that elements have 1 parent, so it could make sense to represent some data as a less restricted form of graph than an XML element tree.
Kendall
On 2/24/17, 10:07 AM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Kendall Shaw" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of kendall.shaw@workday.com> wrote:
For example, a program that regulates flow of water in a garden sprinkler is probably not a good match for xquery and an xml database.
On 2/24/17, 2:20 AM, "meumapple" meumapple@gmail.com wrote:
Hi Kendall,
I do not agree. A few considerations. If data are XML, I find it difficult to use a different language from XQuery. It is possible, of course, but much much more complex (why doing that?!). But native XML files are not the entire story. You can transform, for example, all of text data into an elegant XML working version and very very easily query it. I can do whatever I want with XQuery easily and deal with different kinds of data, so I do not agree at all.
Il giorno 24 feb 2017, alle ore 00:37, Kendall Shaw kendall.shaw@workday.com ha scritto:
What the application is makes all the difference. If the purpose does not have to do with XML and XML in a database, then XQuery and BaseX is less likely to be appropriate.
Kendall
On 2/23/17, 12:36 PM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Maximilian Gärber" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of mgaerber@arcor.de> wrote:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
XML offers an elegant yet simple tree structure. You can find a way to express in XML the kinds of relationships you mention by simply using a different strategy (using not a parent element but, for example, attributes).
In general, every format has limitations (so this is not an XML-related problem, but a more general one). I have also to add that while triples may suit your case, there are hundreds of other cases where they would simply add too much structure you would really prefer to get rid of.
In my experience, XQuery/XPath offers a superb/powerful and yet simple way to handle data (this is especially true in BaseX). XQuery/XPath data model is so terse that compared to others it looks so modern/intuitive/robust. I have recently had to code some Python, and it simply was so gratuitously intricate (and slow).
Joseph
Il giorno 25 feb 2017, alle ore 00:05, Kendall Shaw kendall.shaw@workday.com ha scritto:
A more interesting example, maybe: If you compare XPath with this SPARQL fragment:
?x foaf:knows/foaf:name ?name .
All of my friend’s friend’s friend’s friend’s friend’s etc., with arbitrary depth, who know my friend with name x.
Friends are not limited to having 1 “befriender” in the way that elements have 1 parent, so it could make sense to represent some data as a less restricted form of graph than an XML element tree.
Kendall
On 2/24/17, 10:07 AM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Kendall Shaw" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of kendall.shaw@workday.com> wrote:
For example, a program that regulates flow of water in a garden sprinkler is probably not a good match for xquery and an xml database.
On 2/24/17, 2:20 AM, "meumapple" meumapple@gmail.com wrote:
Hi Kendall,
I do not agree. A few considerations. If data are XML, I find it difficult to use a different language from XQuery. It is possible, of course, but much much more complex (why doing that?!). But native XML files are not the entire story. You can transform, for example, all of text data into an elegant XML working version and very very easily query it. I can do whatever I want with XQuery easily and deal with different kinds of data, so I do not agree at all.
Il giorno 24 feb 2017, alle ore 00:37, Kendall Shaw kendall.shaw@workday.com ha scritto:
What the application is makes all the difference. If the purpose does not have to do with XML and XML in a database, then XQuery and BaseX is less likely to be appropriate.
Kendall
On 2/23/17, 12:36 PM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Maximilian Gärber" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of mgaerber@arcor.de> wrote:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
We users of BaseX probably all agree that it and XQuery are super and powerful. XML ,like RDF, is not a perfect match for every problem. Wordstar is however the solution to every problem.
Kendall
On 2/25/17, 1:28 AM, "meumapple" meumapple@gmail.com wrote:
XML offers an elegant yet simple tree structure. You can find a way to express in XML the kinds of relationships you mention by simply using a different strategy (using not a parent element but, for example, attributes).
In general, every format has limitations (so this is not an XML-related problem, but a more general one). I have also to add that while triples may suit your case, there are hundreds of other cases where they would simply add too much structure you would really prefer to get rid of.
In my experience, XQuery/XPath offers a superb/powerful and yet simple way to handle data (this is especially true in BaseX). XQuery/XPath data model is so terse that compared to others it looks so modern/intuitive/robust. I have recently had to code some Python, and it simply was so gratuitously intricate (and slow).
Joseph
Il giorno 25 feb 2017, alle ore 00:05, Kendall Shaw kendall.shaw@workday.com ha scritto:
A more interesting example, maybe: If you compare XPath with this SPARQL fragment:
?x foaf:knows/foaf:name ?name .
All of my friend’s friend’s friend’s friend’s friend’s etc., with arbitrary depth, who know my friend with name x.
Friends are not limited to having 1 “befriender” in the way that elements have 1 parent, so it could make sense to represent some data as a less restricted form of graph than an XML element tree.
Kendall
On 2/24/17, 10:07 AM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Kendall Shaw" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of kendall.shaw@workday.com> wrote:
For example, a program that regulates flow of water in a garden sprinkler is probably not a good match for xquery and an xml database.
On 2/24/17, 2:20 AM, "meumapple" meumapple@gmail.com wrote:
Hi Kendall,
I do not agree. A few considerations. If data are XML, I find it difficult to use a different language from XQuery. It is possible, of course, but much much more complex (why doing that?!). But native XML files are not the entire story. You can transform, for example, all of text data into an elegant XML working version and very very easily query it. I can do whatever I want with XQuery easily and deal with different kinds of data, so I do not agree at all.
Il giorno 24 feb 2017, alle ore 00:37, Kendall Shaw kendall.shaw@workday.com ha scritto:
What the application is makes all the difference. If the purpose does not have to do with XML and XML in a database, then XQuery and BaseX is less likely to be appropriate.
Kendall
On 2/23/17, 12:36 PM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Maximilian Gärber" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of mgaerber@arcor.de> wrote:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com: > Hi to everyone, > > probably this is not the right place for such a discussion but the BaseX > communitiy is the one I'm better introduced to and the one I trust the most. > So I hope that this somewhat unusual excursus will anyway be of interest to > some of you. > > As for myself I fell in love with XQuery and its power in terms of data > manipulation many years ago. I wouldn't change it with anything else and BTW > we're using it (thanks to the incredible BaseX runtime) much beyond > data-processing being it the backbone of all our micro-service oriented > architectures. > > Now, to the point, in the near future I probably will be called to face a > somewhat skeptical customer who will argue about the technological choice of > XQuery. > > My point will be to make a comparison with the technologies they're > currently using and I would like to demonstrate that for a rather XML- (and > in general data-) intensive workflow XQuery is perfectly suitable and > probably better than many other alternatives. > > I would tend to exclude XSLT because it would face similar opposition. I > would also exclude languages at a lower level of abstraction like Java, > Python, Javascript, C/C++ and so on for obvious architectural reasons. > > But then only templating languages/engines come to my mind. Those would > still be probably novel technologies to learn and wouldn't offer the > structural, syntactic and semantic power of XQuery anyway. > > So I ask you kindly, in order to complete my preparation on these matters, > is there anyone that has experience with other tools or languages that can > be compared with XQuery when used for XML querying, generation, > transformation, templating, composition and so on? > > Thanks a lot! > > Marco.
On Fri, 2017-02-24 at 18:07 +0000, Kendall Shaw wrote:
For example, a program that regulates flow of water in a garden sprinkler is probably not a good match for xquery and an xml database.
Funnily enough, sensors these days often report results using EXI, and an embedded XQuery engine might be a fine way to go. People used to use mxquery for such applications. A lot of tooling choice comes down to warm fuzzies and familiarity.
If you're actually querying XML, then an XML database and XQuery do make an obvious choice. I find it can help to say it's a "fast forest store" with XML as an interchange and loading format, to try & prevent the misunderstanding that the software reads the entire database as pointy-bracket XML with each query and is glacially slow. I wish we'd used a forest metaphor for naming XQuery...
Liam
On 2/24/17, 7:15 PM, "Liam R. E. Quin" liam@w3.org wrote:
On Fri, 2017-02-24 at 18:07 +0000, Kendall Shaw wrote: > For example, a program that regulates flow of water in a garden > sprinkler is probably not a good match for xquery and an xml > database. Funnily enough, sensors these days often report results using EXI, and an embedded XQuery engine might be a fine way to go. People used to use mxquery for such applications.
A lot of tooling choice comes down to warm fuzzies and familiarity.
If you're actually querying XML, then an XML database and XQuery do make an obvious choice. I find it can help to say it's a "fast forest store" with XML as an interchange and loading format, to try & prevent the misunderstanding that the software reads the entire database as pointy-bracket XML with each query and is glacially slow. I wish we'd used a forest metaphor for naming XQuery...
So, maybe, if representing a problem in terms of XQuery’s data model has you using a forest of interrelated stumps, then the tree aspect of forests is not a good match for the problem.
The original post was asking for examples of ways that XQuery is a good solution for an unknown problem. Generally, if I found myself think that technology x is the solution to every problem, I would proceed as if I am probably wrong about that.
It’s interesting to me to know what sorts of applications seem like they would be a good match for XQuery’s data model but turned out not to be in some case.
Kendall
On Sat, 2017-02-25 at 10:02 +0000, Kendall Shaw wrote:
[...]
The original post was asking for examples of ways that XQuery is a good solution for an unknown problem.
Unknown to us at least... yes.
Generally, if I found myself think that technology x is the solution to every problem, I would proceed as if I am probably wrong about that.
:-)
It’s interesting to me to know what sorts of applications seem like they would be a good match for XQuery’s data model but turned out not to be in some case.
I agree that's interesting - I'm afraid I have more experience with what didn't work in SQL and did work with a forest store, probably because I don't often encounter people whose projects didn't fit with XML-related technologies. How do we find them?
I do know of people who moved to JSONiq in order to persist JSON documents alongside XML ones, but XQuery 3.1 might well reduce that pressure. Or at least that was a large part of our goal in the XML Query Working Group in developing it, to improve the XML+JSON and JSON- only support. But JSONiq still has the XQuery support there.
An example of where I probably would not use an XQuery-based system as my first choice might be where I'm dealing with data coming in from 100,000 sensors at a high rate and I have to store, say, the past hour's worth of data for simple queries. The tree-based collection model works best with data that has hierarchy and is, in SQL terms, semi-structured (i.e. has irregularity). XQuery tends to be a win over SQL when a lot of the queries involve hierarchy or sequence, but if those aspects aren't present it's less obviously a win.
Of course, if the sensors are sending EXI-compressed XML parse events, and the db supports that, an XML db can be a win even there; I heard from someone who experimented with devices that could send either JSON or EXI, and he was blown away at the performance improvement he got by switching to EXI. So you have to measure and experiment, too.
best,
Liam
On 2/25/17, 12:55 PM, "Liam R. E. Quin" liam@w3.org wrote:
On Sat, 2017-02-25 at 10:02 +0000, Kendall Shaw wrote: > It’s interesting to me to know what sorts of applications seem like > they would be a good match for XQuery’s data model but turned out not > to be in some case.
I agree that's interesting - I'm afraid I have more experience with what didn't work in SQL and did work with a forest store, probably because I don't often encounter people whose projects didn't fit with XML-related technologies. How do we find them?
Aside from things like the 100,000 sensors scenario that you described, the friends example might be a case that is in the same area that XML makes sense.
With XPath having special support for hierarchical data, matching XML’s notion of element hierarchy, it’s perfect for data like:
<totem-pole> <person name=”cindy”> <person name=”karen”> <person name=”linda”> <person name=”sarah”> <person name=”wendy”/> </person> </person> </person> </person> </totem-pole>
So you can us $person//*/@name to get cindy’s sub-friends. Also, the document is constrained to be well-formed by the rules of XML document types, based on elements having only 1 parent. But, friends aren’t constrained to have only have 1 super-friend. And poor Wendy gets no sub-friends.
A less restricted graph representation can represent that where hierarchy doesn’t have special status:
@prefix : <people#> . :cindy :name “cindy” ; :knows :karen . :karen :name “karen” ; :knows :linda . :linda :name “linda” ; :knows :sarah . :sarah :name “sarah” ; :knows :wendy . :wendy :name “wendy” :knows :cindy .
And with SPARQL, having special support for graph traversal, matching RDF’s notion of connected edges, it’s perfect for data like above.
So, you can use ?p :knows/:name ?name to get cindy’s friend’s friend’s friend’s friend’s etc. Also, Wendy gets to have a friend too.
Representing something similar in XML, ignoring RDF XML which makes it even more complicated:
<friends> <person name=”cindy” knows=”karen”/> <person name=”karen” knows=”linda”/> <person name=”linda” knows=”sarah”/> <person name=”sarah” knows=”wendy”/> <person name=”wendy”/> </friends>
The rules of XML document types don’t include special support for arbitrary attribute relationships, in the way that element hierarchy does have special status. You can write XQuery to navigate that data, but it’s not a simple expression and doesn’t use ancestor/descendant axes so maybe it’s not the best choice for the data.
The other way around, when most of the data is hierarchical it’s harder to use something like SPARQL with RDF than XPath with XML. And RDF is not necessarily the best representation for graphs where nodes and edges both have attributes.
Kendall
Hi Kendal --
If you don't stick to attributes, it's not hard to represent that kind of relationship graph in XML:
<people> <person name="cindy"> <knows>karen</knows> </person> <person name="karen"> <knows>linda</knows> </person> <person name="linda"> <knows>sarah</knows> </person> <person name="sarah"> <knows>wendy</knows> </person> <person name="wendy"> <knows>cindy</knows> </person> </people>
This way you can have a lot of <knows> elements (edges in the relationship graph) for an individual. The XML graph and the represented graph don't match structurally and you'd have to go through and build maps or something in XQuery to manipulate the represented graph, but writing a function to get everybody who knows Cindy within a certain number of edges wouldn't be difficult. (Taking off the "certain number of edges" obliges you to write some sort of cycle detection mechanism, which is harder and presumably the people behind SPARQL have already done so.)
So not quite as syntactically compact but I don't think XML is obviously unsuitable for "represent an arbitrary graph". You have to pick your XML vocabulary carefully but "arbitrary graph" and "carefully" go naturally together.
-- Graydon
On Sat, Feb 25, 2017 at 7:42 PM, Kendall Shaw kendall.shaw@workday.com wrote:
On 2/25/17, 12:55 PM, "Liam R. E. Quin" liam@w3.org wrote:
On Sat, 2017-02-25 at 10:02 +0000, Kendall Shaw wrote: > It’s interesting to me to know what sorts of applications seem like > they would be a good match for XQuery’s data model but turned out not > to be in some case. I agree that's interesting - I'm afraid I have more experience with what didn't work in SQL and did work with a forest store, probably because I don't often encounter people whose projects didn't fit with XML-related technologies. How do we find them?Aside from things like the 100,000 sensors scenario that you described, the friends example might be a case that is in the same area that XML makes sense.
With XPath having special support for hierarchical data, matching XML’s notion of element hierarchy, it’s perfect for data like:
<totem-pole> <person name=”cindy”> <person name=”karen”> <person name=”linda”> <person name=”sarah”> <person name=”wendy”/> </person> </person> </person> </person> </totem-pole>
So you can us $person//*/@name to get cindy’s sub-friends. Also, the document is constrained to be well-formed by the rules of XML document types, based on elements having only 1 parent. But, friends aren’t constrained to have only have 1 super-friend. And poor Wendy gets no sub-friends.
A less restricted graph representation can represent that where hierarchy doesn’t have special status:
@prefix : <people#> . :cindy :name “cindy” ; :knows :karen . :karen :name “karen” ; :knows :linda . :linda :name “linda” ; :knows :sarah . :sarah :name “sarah” ; :knows :wendy . :wendy :name “wendy” :knows :cindy .
And with SPARQL, having special support for graph traversal, matching RDF’s notion of connected edges, it’s perfect for data like above.
So, you can use ?p :knows/:name ?name to get cindy’s friend’s friend’s friend’s friend’s etc. Also, Wendy gets to have a friend too.
Representing something similar in XML, ignoring RDF XML which makes it even more complicated:
<friends> <person name=”cindy” knows=”karen”/> <person name=”karen” knows=”linda”/> <person name=”linda” knows=”sarah”/> <person name=”sarah” knows=”wendy”/> <person name=”wendy”/> </friends>
The rules of XML document types don’t include special support for arbitrary attribute relationships, in the way that element hierarchy does have special status. You can write XQuery to navigate that data, but it’s not a simple expression and doesn’t use ancestor/descendant axes so maybe it’s not the best choice for the data.
The other way around, when most of the data is hierarchical it’s harder to use something like SPARQL with RDF than XPath with XML. And RDF is not necessarily the best representation for graphs where nodes and edges both have attributes.
Kendall
I think it’s important to the original question to point out that a problem is likely to includes mixtures of different types of data. BaseX has an SQL module and Marklogic includes modules for RDF and you can write extensions and use http to integrate external systems in various XML database systems.
For the skeptical person that we are pitching XQuery and BaseX to it’s probably best to be prepared to describe a solution that isn’t unnaturally forcing XML to fit as the solution for every problem.
Kendall
From: Graydon Saunders graydonish@gmail.com Date: Saturday, February 25, 2017 at 5:09 PM To: Kendall Shaw kendall.shaw@workday.com Cc: BaseX basex-talk@mailman.uni-konstanz.de Subject: Re: [basex-talk] Somewhat unusual question
Hi Kendal --
If you don't stick to attributes, it's not hard to represent that kind of relationship graph in XML:
<people> <person name="cindy"> <knows>karen</knows> </person> <person name="karen"> <knows>linda</knows> </person> <person name="linda"> <knows>sarah</knows> </person> <person name="sarah"> <knows>wendy</knows> </person> <person name="wendy"> <knows>cindy</knows> </person> </people>
This way you can have a lot of <knows> elements (edges in the relationship graph) for an individual. The XML graph and the represented graph don't match structurally and you'd have to go through and build maps or something in XQuery to manipulate the represented graph, but writing a function to get everybody who knows Cindy within a certain number of edges wouldn't be difficult. (Taking off the "certain number of edges" obliges you to write some sort of cycle detection mechanism, which is harder and presumably the people behind SPARQL have already done so.)
So not quite as syntactically compact but I don't think XML is obviously unsuitable for "represent an arbitrary graph". You have to pick your XML vocabulary carefully but "arbitrary graph" and "carefully" go naturally together.
-- Graydon
On Sat, Feb 25, 2017 at 7:42 PM, Kendall Shaw <kendall.shaw@workday.commailto:kendall.shaw@workday.com> wrote: On 2/25/17, 12:55 PM, "Liam R. E. Quin" <liam@w3.orgmailto:liam@w3.org> wrote:
On Sat, 2017-02-25 at 10:02 +0000, Kendall Shaw wrote: > It’s interesting to me to know what sorts of applications seem like > they would be a good match for XQuery’s data model but turned out not > to be in some case.
I agree that's interesting - I'm afraid I have more experience with what didn't work in SQL and did work with a forest store, probably because I don't often encounter people whose projects didn't fit with XML-related technologies. How do we find them?
Aside from things like the 100,000 sensors scenario that you described, the friends example might be a case that is in the same area that XML makes sense.
With XPath having special support for hierarchical data, matching XML’s notion of element hierarchy, it’s perfect for data like:
<totem-pole> <person name=”cindy”> <person name=”karen”> <person name=”linda”> <person name=”sarah”> <person name=”wendy”/> </person> </person> </person> </person> </totem-pole>
So you can us $person//*/@name to get cindy’s sub-friends. Also, the document is constrained to be well-formed by the rules of XML document types, based on elements having only 1 parent. But, friends aren’t constrained to have only have 1 super-friend. And poor Wendy gets no sub-friends.
A less restricted graph representation can represent that where hierarchy doesn’t have special status:
@prefix : <people#> . :cindy :name “cindy” ; :knows :karen . :karen :name “karen” ; :knows :linda . :linda :name “linda” ; :knows :sarah . :sarah :name “sarah” ; :knows :wendy . :wendy :name “wendy” :knows :cindy .
And with SPARQL, having special support for graph traversal, matching RDF’s notion of connected edges, it’s perfect for data like above.
So, you can use ?p :knows/:name ?name to get cindy’s friend’s friend’s friend’s friend’s etc. Also, Wendy gets to have a friend too.
Representing something similar in XML, ignoring RDF XML which makes it even more complicated:
<friends> <person name=”cindy” knows=”karen”/> <person name=”karen” knows=”linda”/> <person name=”linda” knows=”sarah”/> <person name=”sarah” knows=”wendy”/> <person name=”wendy”/> </friends>
The rules of XML document types don’t include special support for arbitrary attribute relationships, in the way that element hierarchy does have special status. You can write XQuery to navigate that data, but it’s not a simple expression and doesn’t use ancestor/descendant axes so maybe it’s not the best choice for the data.
The other way around, when most of the data is hierarchical it’s harder to use something like SPARQL with RDF than XPath with XML. And RDF is not necessarily the best representation for graphs where nodes and edges both have attributes.
Kendall
To put it mildly, I disagree. I think the greatest mistake one can make is call XQuery a query language. I prefer to say that it is an information language. If this appears to be an incomprehensible statement, this reflects the novelty of the concept of an "information language". A book should be written about it. Which points to my ...
second disagreement, which concerns your statement that there is nothing special about XQuery. I think XQuery is unique, as it is (or am I wrong?) the first and only general-purpose programming language which is a pure expression language built upon the ground of a value model centered in the concept of resources composed of globally addressable, interrelated information (i.e. nodes). With kind regards,Hans-Jürgen
Maximilian Gärber mgaerber@arcor.de schrieb am 21:36 Donnerstag, 23.Februar 2017:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
I agree entirely that XQuery is unique and that calling it a query language gives the wrong impression. I gave a talk about this last August at Balisage:
http://www.balisage.net/Proceedings/vol18/html/Murray01/BalisageVol18-Murray...
Regards, Greg
From: <basex-talk-bounces@mailman.uni-konstanz.demailto:basex-talk-bounces@mailman.uni-konstanz.de> on behalf of Hans-Juergen Rennau <hrennau@yahoo.demailto:hrennau@yahoo.de> Reply-To: Hans-Juergen Rennau <hrennau@yahoo.demailto:hrennau@yahoo.de> Date: Friday, February 24, 2017 at 6:56 AM To: Maximilian Gärber <mgaerber@arcor.demailto:mgaerber@arcor.de>, "basex-talk@mailman.uni-konstanz.demailto:basex-talk@mailman.uni-konstanz.de" <basex-talk@mailman.uni-konstanz.demailto:basex-talk@mailman.uni-konstanz.de> Subject: Re: [basex-talk] Somewhat unusual question
To put it mildly, I disagree. I think the greatest mistake one can make is call XQuery a query language. I prefer to say that it is an information language. If this appears to be an incomprehensible statement, this reflects the novelty of the concept of an "information language". A book should be written about it. Which points to my ...
second disagreement, which concerns your statement that there is nothing special about XQuery. I think XQuery is unique, as it is (or am I wrong?) the first and only general-purpose programming language which is a pure expression language built upon the ground of a value model centered in the concept of resources composed of globally addressable, interrelated information (i.e. nodes).
With kind regards, Hans-Jürgen
Maximilian Gärber <mgaerber@arcor.demailto:mgaerber@arcor.de> schrieb am 21:36 Donnerstag, 23.Februar 2017:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere <m.lettere@gmail.commailto:m.lettere@gmail.com>:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
Nice article Greg!
Paul
On 24-2-2017 14:29, Murray, Gregory wrote:
I agree entirely that XQuery is unique and that calling it a query language gives the wrong impression. I gave a talk about this last August at Balisage:
http://www.balisage.net/Proceedings/vol18/html/Murray01/BalisageVol18-Murray...
Regards, Greg
From: <basex-talk-bounces@mailman.uni-konstanz.de mailto:basex-talk-bounces@mailman.uni-konstanz.de> on behalf of Hans-Juergen Rennau <hrennau@yahoo.de mailto:hrennau@yahoo.de> Reply-To: Hans-Juergen Rennau <hrennau@yahoo.de mailto:hrennau@yahoo.de> Date: Friday, February 24, 2017 at 6:56 AM To: Maximilian Gärber <mgaerber@arcor.de mailto:mgaerber@arcor.de>, "basex-talk@mailman.uni-konstanz.de mailto:basex-talk@mailman.uni-konstanz.de" <basex-talk@mailman.uni-konstanz.de mailto:basex-talk@mailman.uni-konstanz.de> Subject: Re: [basex-talk] Somewhat unusual question
To put it mildly, I disagree. I think the greatest mistake one can make is call XQuery a query language. I prefer to say that it is an information language. If this appears to be an incomprehensible statement, this reflects the novelty of the concept of an "information language". A book should be written about it. Which points to my ...
second disagreement, which concerns your statement that there is nothing special about XQuery. I think XQuery is unique, as it is (or am I wrong?) the first and only general-purpose programming language which is a pure expression language built upon the ground of a value model centered in the concept of resources composed of globally addressable, interrelated information (i.e. nodes).
With kind regards, Hans-Jürgen
Maximilian Gärber <mgaerber@arcor.de mailto:mgaerber@arcor.de> schrieb am 21:36 Donnerstag, 23.Februar 2017:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere <m.lettere@gmail.com mailto:m.lettere@gmail.com>:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust
the most.
So I hope that this somewhat unusual excursus will anyway be of
interest to
some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else
and BTW
we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to
face a
somewhat skeptical customer who will argue about the technological
choice of
XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather
XML- (and
in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these
matters,
is there anyone that has experience with other tools or languages
that can
be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
Hi,
I really like this thread! Keep the arguments coming! ;-)
I am not saying that XQuery is just another query language. But if somebody (who has never heard anything about XQuery) is asking about your technological choice then telling them that XQuery is so special and unique is counter-productive.
Because business decisions are always the same when it comes to technology: they want this warm and fuzzy feeling that you are running on mainstream stuff.
Br, Max
2017-02-24 12:56 GMT+01:00 Hans-Juergen Rennau hrennau@yahoo.de:
To put it mildly, I disagree. I think the greatest mistake one can make is call XQuery a query language. I prefer to say that it is an information language. If this appears to be an incomprehensible statement, this reflects the novelty of the concept of an "information language". A book should be written about it. Which points to my ...
second disagreement, which concerns your statement that there is nothing special about XQuery. I think XQuery is unique, as it is (or am I wrong?) the first and only general-purpose programming language which is a pure expression language built upon the ground of a value model centered in the concept of resources composed of globally addressable, interrelated information (i.e. nodes).
With kind regards, Hans-Jürgen
Maximilian Gärber mgaerber@arcor.de schrieb am 21:36 Donnerstag, 23.Februar 2017:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
Hello Max,
I think business decisions follow that path to avoid ending up in a niche area where it would be terribly difficult to employ a replacement once a/the developer has left. Perhaps also pointing out that there are standards and perhaps that it's not too difficult to learn would help to allay fears?
hth adil
On Fri, Feb 24, 2017 at 03:06:59PM +0100, Maximilian Gärber wrote:
Hi,
I really like this thread! Keep the arguments coming! ;-)
I am not saying that XQuery is just another query language. But if somebody (who has never heard anything about XQuery) is asking about your technological choice then telling them that XQuery is so special and unique is counter-productive.
Because business decisions are always the same when it comes to technology: they want this warm and fuzzy feeling that you are running on mainstream stuff.
Br, Max
2017-02-24 12:56 GMT+01:00 Hans-Juergen Rennau hrennau@yahoo.de:
To put it mildly, I disagree. I think the greatest mistake one can make is call XQuery a query language. I prefer to say that it is an information language. If this appears to be an incomprehensible statement, this reflects the novelty of the concept of an "information language". A book should be written about it. Which points to my ...
second disagreement, which concerns your statement that there is nothing special about XQuery. I think XQuery is unique, as it is (or am I wrong?) the first and only general-purpose programming language which is a pure expression language built upon the ground of a value model centered in the concept of resources composed of globally addressable, interrelated information (i.e. nodes).
With kind regards, Hans-Jürgen
Maximilian Gärber mgaerber@arcor.de schrieb am 21:36 Donnerstag, 23.Februar 2017:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
Hi guys, thank you all so much for the great feedback. This one in particular feels like a crucial point and it's why I'm currently collecting all possible feedback also from students, stagers and other technicians that are somehow representative of entry-level to basic staff. Nice to see that people with fresh minds are extremely positive about the simplicity and the productivity of XQuery even if confronted with non XML specific use cases! Marco.
On 24/02/2017 15:25, Adil Hasan wrote:
Hello Max,
I think business decisions follow that path to avoid ending up in a niche area where it would be terribly difficult to employ a replacement once a/the developer has left. Perhaps also pointing out that there are standards and perhaps that it's not too difficult to learn would help to allay fears?
hth adil
On Fri, Feb 24, 2017 at 03:06:59PM +0100, Maximilian Gärber wrote:
Hi,
I really like this thread! Keep the arguments coming! ;-)
I am not saying that XQuery is just another query language. But if somebody (who has never heard anything about XQuery) is asking about your technological choice then telling them that XQuery is so special and unique is counter-productive.
Because business decisions are always the same when it comes to technology: they want this warm and fuzzy feeling that you are running on mainstream stuff.
Br, Max
2017-02-24 12:56 GMT+01:00 Hans-Juergen Rennau hrennau@yahoo.de:
To put it mildly, I disagree. I think the greatest mistake one can make is call XQuery a query language. I prefer to say that it is an information language. If this appears to be an incomprehensible statement, this reflects the novelty of the concept of an "information language". A book should be written about it. Which points to my ...
second disagreement, which concerns your statement that there is nothing special about XQuery. I think XQuery is unique, as it is (or am I wrong?) the first and only general-purpose programming language which is a pure expression language built upon the ground of a value model centered in the concept of resources composed of globally addressable, interrelated information (i.e. nodes).
With kind regards, Hans-Jürgen
Maximilian Gärber mgaerber@arcor.de schrieb am 21:36 Donnerstag, 23.Februar 2017:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
Hello Marco,
I think Max is spot on, that the main objection of business people is that XQuery is not exactly mainstream stuff. Nobody will be questioned if you buy Oracle and your project in the end fails - Hey, you bought the established market leader, what could go wrong? But you use a relatively unknown, open source database (BaseX comes to mind...) and the project fails - Hey, everyone will criticize this decision, for sure.
However, to at least decrease the fears it might be worth mentioning the standardization efforts and open source software involved:
- XQuery, XPath, etc.pp. are all W3C standards
- There are several XQuery implementations (BaseX, exist-db, MarkLogic), so even in the case your platform in the end might not be maintained anymore you might be able to change to another implementation
- Functional languages are quite "in" at the moment (look at the success of Haskell, Clojure, Scala, Erlang, ...). With XQuery being also a functional language it is quite easier for those developers also to grasp XQuery. So you should have an increasing number of at least potential XQuery developers
- Using BaseX (or exist-db) as your XQuery processor you use open source software, which has several business benefits (e.g. decreased risk of vendor lock in)
- Using BaseX (or exist-db) you can get get commercial supports from the companies behind these open source tools. For some reason, business people love to buy commercial support...
I hope you can convince them - Wish you all the best
Dirk
On 02/24/2017 06:06 PM, Marco Lettere wrote:
Hi guys, thank you all so much for the great feedback. This one in particular feels like a crucial point and it's why I'm currently collecting all possible feedback also from students, stagers and other technicians that are somehow representative of entry-level to basic staff. Nice to see that people with fresh minds are extremely positive about the simplicity and the productivity of XQuery even if confronted with non XML specific use cases! Marco.
On 24/02/2017 15:25, Adil Hasan wrote:
Hello Max,
I think business decisions follow that path to avoid ending up in a niche area where it would be terribly difficult to employ a replacement once a/the developer has left. Perhaps also pointing out that there are standards and perhaps that it's not too difficult to learn would help to allay fears?
hth adil
On Fri, Feb 24, 2017 at 03:06:59PM +0100, Maximilian Gärber wrote:
Hi,
I really like this thread! Keep the arguments coming! ;-)
I am not saying that XQuery is just another query language. But if somebody (who has never heard anything about XQuery) is asking about your technological choice then telling them that XQuery is so special and unique is counter-productive.
Because business decisions are always the same when it comes to technology: they want this warm and fuzzy feeling that you are running on mainstream stuff.
Br, Max
2017-02-24 12:56 GMT+01:00 Hans-Juergen Rennau hrennau@yahoo.de:
To put it mildly, I disagree. I think the greatest mistake one can make is call XQuery a query language. I prefer to say that it is an information language. If this appears to be an incomprehensible statement, this reflects the novelty of the concept of an "information language". A book should be written about it. Which points to my ...
second disagreement, which concerns your statement that there is nothing special about XQuery. I think XQuery is unique, as it is (or am I wrong?) the first and only general-purpose programming language which is a pure expression language built upon the ground of a value model centered in the concept of resources composed of globally addressable, interrelated information (i.e. nodes).
With kind regards, Hans-Jürgen
Maximilian Gärber mgaerber@arcor.de schrieb am 21:36 Donnerstag, 23.Februar 2017:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
Hello Marco, I'm sure your thinking like this: look at it from the customer's point of view. They will view the s/w as a means to a enabling them to get their product to the consumer more cheaply or quickly or to allow them to reach more consumers.
From that viewpoint here's a few points to consider:
- is Xquery easy to learn and use? - is it cheap? - is it secure? - is it faster? - does it scale? - how difficult is it to port what we have to using Xquery? - is it easy to maintain?
As Dirk says below you also should point out the XML database products exist and are relatively mature with good support. Business people are risk-averse when it comes to tools required to build their product (unless the new tool offers such a compelling advantage that the risk is worth taking).
It may be worth demonstrating that a novice user was able to get some Xquery example up and running in a short time. Or, showing some demo that is a mock-up of some component of their system and describe how long it took to put together (perhaps compare with a similar approach with another s/w).
hth adil
On Fri, Feb 24, 2017 at 07:55:25PM +0330, Dirk Kirsten wrote:
Hello Marco,
I think Max is spot on, that the main objection of business people is that XQuery is not exactly mainstream stuff. Nobody will be questioned if you buy Oracle and your project in the end fails - Hey, you bought the established market leader, what could go wrong? But you use a relatively unknown, open source database (BaseX comes to mind...) and the project fails - Hey, everyone will criticize this decision, for sure.
However, to at least decrease the fears it might be worth mentioning the standardization efforts and open source software involved:
XQuery, XPath, etc.pp. are all W3C standards
There are several XQuery implementations (BaseX, exist-db, MarkLogic),
so even in the case your platform in the end might not be maintained anymore you might be able to change to another implementation
- Functional languages are quite "in" at the moment (look at the success
of Haskell, Clojure, Scala, Erlang, ...). With XQuery being also a functional language it is quite easier for those developers also to grasp XQuery. So you should have an increasing number of at least potential XQuery developers
- Using BaseX (or exist-db) as your XQuery processor you use open source
software, which has several business benefits (e.g. decreased risk of vendor lock in)
- Using BaseX (or exist-db) you can get get commercial supports from the
companies behind these open source tools. For some reason, business people love to buy commercial support...
I hope you can convince them - Wish you all the best
Dirk
On 02/24/2017 06:06 PM, Marco Lettere wrote:
Hi guys, thank you all so much for the great feedback. This one in particular feels like a crucial point and it's why I'm currently collecting all possible feedback also from students, stagers and other technicians that are somehow representative of entry-level to basic staff. Nice to see that people with fresh minds are extremely positive about the simplicity and the productivity of XQuery even if confronted with non XML specific use cases! Marco.
On 24/02/2017 15:25, Adil Hasan wrote:
Hello Max,
I think business decisions follow that path to avoid ending up in a niche area where it would be terribly difficult to employ a replacement once a/the developer has left. Perhaps also pointing out that there are standards and perhaps that it's not too difficult to learn would help to allay fears?
hth adil
On Fri, Feb 24, 2017 at 03:06:59PM +0100, Maximilian Gärber wrote:
Hi,
I really like this thread! Keep the arguments coming! ;-)
I am not saying that XQuery is just another query language. But if somebody (who has never heard anything about XQuery) is asking about your technological choice then telling them that XQuery is so special and unique is counter-productive.
Because business decisions are always the same when it comes to technology: they want this warm and fuzzy feeling that you are running on mainstream stuff.
Br, Max
2017-02-24 12:56 GMT+01:00 Hans-Juergen Rennau hrennau@yahoo.de:
To put it mildly, I disagree. I think the greatest mistake one can make is call XQuery a query language. I prefer to say that it is an information language. If this appears to be an incomprehensible statement, this reflects the novelty of the concept of an "information language". A book should be written about it. Which points to my ...
second disagreement, which concerns your statement that there is nothing special about XQuery. I think XQuery is unique, as it is (or am I wrong?) the first and only general-purpose programming language which is a pure expression language built upon the ground of a value model centered in the concept of resources composed of globally addressable, interrelated information (i.e. nodes).
With kind regards, Hans-Jürgen
Maximilian Gärber mgaerber@arcor.de schrieb am 21:36 Donnerstag, 23.Februar 2017:
Hi Marco,
from my experience, the best way to handle these types of arguments is to make clear that there is nothing 'special' about XQuery. It is a query language.
If you have to compare BaseX to something that most Java developers will know, I'd use Hibernate and HQL, a library and DSL that is all about querying data(bases).
For C# developers, LINQ would probably ring a bell.
Of course there is a lot more to it, and when it comes to web applications, you can use it in almost every layer (templating, routing, storage, etc).
Regards,
Max
2017-02-22 13:43 GMT+01:00 Marco Lettere m.lettere@gmail.com:
Hi to everyone,
probably this is not the right place for such a discussion but the BaseX communitiy is the one I'm better introduced to and the one I trust the most. So I hope that this somewhat unusual excursus will anyway be of interest to some of you.
As for myself I fell in love with XQuery and its power in terms of data manipulation many years ago. I wouldn't change it with anything else and BTW we're using it (thanks to the incredible BaseX runtime) much beyond data-processing being it the backbone of all our micro-service oriented architectures.
Now, to the point, in the near future I probably will be called to face a somewhat skeptical customer who will argue about the technological choice of XQuery.
My point will be to make a comparison with the technologies they're currently using and I would like to demonstrate that for a rather XML- (and in general data-) intensive workflow XQuery is perfectly suitable and probably better than many other alternatives.
I would tend to exclude XSLT because it would face similar opposition. I would also exclude languages at a lower level of abstraction like Java, Python, Javascript, C/C++ and so on for obvious architectural reasons.
But then only templating languages/engines come to my mind. Those would still be probably novel technologies to learn and wouldn't offer the structural, syntactic and semantic power of XQuery anyway.
So I ask you kindly, in order to complete my preparation on these matters, is there anyone that has experience with other tools or languages that can be compared with XQuery when used for XML querying, generation, transformation, templating, composition and so on?
Thanks a lot!
Marco.
-- Dirk Kirsten, BaseX GmbH, http://basexgmbh.de |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle `-- Phone: 0049 7531 91 68 276, Fax: 0049 7531 20 05 22
Hi,
I was following this thread last week but couldn't chime in yet as I was inundated with work. I am, in a sense, lucky to be able to spend about 2/3 to 3/4 of my time on XQuery and XSLT. It used to be just XSLT but we started using XQuery more and nowadays it's predominantly XQuery (with BaseX of course).
I saw this thread shift towards the merits of XQuery applications in a commercial context. The original question was about a comparison between XQuery and other languages. Marco said that he was anticipating some pushback, or at least some difficulty in proposing an XQuery or even XML-based solution for a client. Maybe I can tell a something about the role XQuery or XML technologies play in our company which is a marketing operations company with many international clients.
I use XQuery for fun and for commercial work. I have also used XSLT extensively for about 15 years. From the start I was able to apply XML technologies on commercial projects. Only quite recently I came to XQuery. Having dabbled with Marklogic and Exist before I knew about XML databases and XQuery. Then I "found" BaseX and about 2 years ago I started to introduce it at work. First for small adhoc jobs, or for, what I call, "glue". But soon for applications that sit beside or are integrated with our main systems or products. Our company has bought into XML technologies from the beginning more than 10 years ago. Mainly XSL-FO and XSLT. Mostly for quite traditional publishing use-cases. Even though our main products are built with Java and we are thus quite a mainstream software development shop we are also not afraid of applying XML technologies where it makes sense.
Our development team is trusted by the business to make their own technology choices. In many cases the business doesn't even care which technology is used to build something. They mostly care about what it can do, how quickly we can build it and how reliable it is. Of course this is not a green-field and we do have to build solutions that operate with or inside our existing applications (which happen to be written in Java for the most part).
We are a marketing operations company and our systems are used by marketing departments of large international clients in retail, government, publishing, manufacturing, automotive and other areas. Where does XQuery, or XML technology in general, fit within our main on-line applications? Here are some examples of areas where it is beneficial for us.
- Publishing: XSLT, XSL-FO and increasingly XQuery are used to create printed materials such as catalogs, posters, brochures, business cards etc. But also micro-sites or web-apps that sales staff can take on the road with them to talk to their customers. The content for these products can be authored in an XML-based system that gives it's users an almost WYSIWYG view of the finished product. Or it can be provided and edited in a configurable database/content mangement system that acts as an on-line ordering system for these products. XQuery is also used for publishing projects that cannot be handled by our existing systems. An example is generating an annual report web site for one of our clients.
- Order fulfillment: when our clients order products via one of our systems they need to have it rendered. Often into PDF for printing but also for on-line use such as publication on their own web-site. Also, each client may have different requirements for fulfilling orders. Some require submitting files to a printer's web-service, or they require order data in the form of spreadsheets. Some are pushed to one of our other systems to be handled by our internal staff. XQuery orchestrates the rendering and reporting (often with XSLT) for these orders in a way that gives each client what they need.
- Content APIs: our customizable content management system is a Java application with a RDBMS. It may store anything from printable products, articles with textual content or even a detailed inventory with photos of all the retail stores of a client. To access this data more easily we developed an XQuery and BaseX integration that will have a synced version of all this system's data in XML format. Any of our internal services (such as the above mentioned order fulfillment service) can use this XQuery-based content API to get the relevant data from this content management system.
- Data & Content Engineering: frequently we are tasked with assignments that cannot be handled by our regular systems. A good example is processing and transforming the data representing the complete and detailed inventory of all 500+ stores from a retail client and bringing it into our content management system used by the client to plan their marketing campaigns for their stores. From this case I learned that XQuery is very well suited for this type of job. Another good example is enabling translation of our applications, preparing UI and content for translation, processing the translated content and merging it back into the application.
So, to sum it up. XML-based technologies, XQuery included, is proving it's value for us each and every day and using it succesfully also helps pave the way for increased usage in our company especially when dealing with publishing and data processing. Most often you will see them appear in between systems (as glue) or at the edges of a system (to deal with special requirements) as these parts often require more flexibility.
I'm always trying to be open to alternative technologies for implementation and often I challenge others by asking for alternative solutions when I pitch the idea of using XML technology. I like to think that I have enough general knowledge of other languages to be able to advocate XML-tech when I think it is a better fit for the job. And I also think that we stay critical once a solution is chosen.
I do admit, however, that it is often more easy to hire a new Java developer than it is to hire an XML developer. In our company both exist side-by-side in the same team, and sometimes even in the same person.
In fact, I wrote this long response not only as an answer to this thread but also to let you know that we could use a new team member. Especially one that knows XML technologies well. In particular XSL-FO, XSLT and XQuery. But if you also have experience in either Java development or front-end Javascript development that would be even better. We, the IT team, operate from Eindhoven in the Netherlands but we have our headquarters in Manchester in the UK. If your are interested in knowing more about this opportunity then reply to me in private.
--Marc
basex-talk@mailman.uni-konstanz.de
-
Adil Hasan -
Dirk Kirsten -
Fabrice ETANCHAUD -
Graydon Saunders -
Hans-Juergen Rennau -
Kendall Shaw -
Kristian Kankainen -
Liam R. E. Quin -
Marc van Grootel -
Marco Lettere -
Maximilian Gärber -
meumapple -
Murray, Gregory -
Paul Swennenhuis