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