Hello all,
I discovered BaseX recently and I find it really powerfull. Unfortunately, I read that versioning was not supported out of the box in 2014 [1]. Is it still the case ? Is there no simple workaround ?
My usecase is the following. I have thousands of XML files which are indexed using BaseX in a specific database, lets say "mydb". At some point of time, a user may want to add a new XML file which is a slightly modified version of one already indexed by BaseX.
I would like to be able to:
- store this new XML resource in "mydb" database without loosing the XML from which it is issued - to retrieve the latest version or a previous one. - filter resources based on the latest version
A simple way to achieve such a behaviour would be to be able to index a XML resource in BaseX with some additional meta information such as an ID and a timestamp, and then offer the possibility to use these meta information in an XQuery to filter resources.
Is it possible with BaseX 8.3 ?
I am looking for a solution that does not a require another database.
[1] https://mailman.uni-konstanz.de/pipermail/basex-talk/2014-March/006535.html
Kind Regards,
Laurent Pellegrino
Hi Laurent,
I discovered BaseX recently and I find it really powerfull. Unfortunately, I read that versioning was not supported out of the box in 2014 [1]. Is it still the case ? Is there no simple workaround ?
BaseX does not come with an out-of-the-box solution for versioning XML documents, but there are many ways to realize this via XQuery or the existing commands. You could e.g. attach timestamps in the database file paths or update information in an additional XML meta file with each request. We have also started defining document metadata properties [1], but this is still work in progress.
A simple way to achieve such a behaviour would be to be able to index a XML resource in BaseX with some additional meta information such as an ID and a timestamp, and then offer the possibility to use these meta information in an XQuery to filter resources.
Is it possible with BaseX 8.3 ?
This is absolutely possible. I don’t know how much time you have already spent with XQuery, but could check out our Wiki articles on XQuery Update [2] and the Database Module [3].
Hope this helps, Christian
[1] https://github.com/BaseXdb/basex/issues/988 [2] http://docs.basex.org/wiki/XQuery_Update [3] http://docs.basex.org/wiki/Database_Module
On Wed, Dec 23, 2015 at 2:18 PM, Laurent Pellegrino laurent.pellegrino@activeeon.com wrote:
Hello all,
I discovered BaseX recently and I find it really powerfull. Unfortunately, I read that versioning was not supported out of the box in 2014 [1]. Is it still the case ? Is there no simple workaround ?
My usecase is the following. I have thousands of XML files which are indexed using BaseX in a specific database, lets say "mydb". At some point of time, a user may want to add a new XML file which is a slightly modified version of one already indexed by BaseX.
I would like to be able to:
- store this new XML resource in "mydb" database without loosing the XML
from which it is issued
- to retrieve the latest version or a previous one.
- filter resources based on the latest version
A simple way to achieve such a behaviour would be to be able to index a XML resource in BaseX with some additional meta information such as an ID and a timestamp, and then offer the possibility to use these meta information in an XQuery to filter resources.
Is it possible with BaseX 8.3 ?
I am looking for a solution that does not a require another database.
[1] https://mailman.uni-konstanz.de/pipermail/basex-talk/2014-March/006535.html
Kind Regards,
Laurent Pellegrino
Hi,
I am using map:merge to construct a map from smaller maps and would like to preserve values when keys agree. For example, when calling
map:merge((map:entry(0, "red"), (map:entry(1, "green"), map:entry(1, "blue")))
I would like to get back something like
map { 0: "red", 1: ("green", "blue") }
The default (W3C) behavior is to drop "green" in favor of "blue".
Is there a simple way to accomplish this? I realize the above example is mixing types so presumably a solution would have all values as sets.
Thanks, Ron
Try this:
let $maps := ( map:entry(0, "red"), map:entry(1, "green"), map:entry(1, "blue") ) return map:merge( for $map in $maps for $key in map:keys($map) group by $key return map { $key : $map ! .($key) } )
This is an equivalent, possibly better readable, solution:
let $maps := ( map:entry(0, "red"), map:entry(1, "green"), map:entry(1, "blue") ) let $keys := distinct-values( for $map in $maps return map:keys($map) ) return map:merge( for $key in $keys let $value := for $map in $maps return $map($key) return map { $key : $value } )
On Wed, Dec 23, 2015 at 11:04 PM, Ron Katriel rkatriel@mdsol.com wrote:
Hi,
I am using map:merge to construct a map from smaller maps and would like to preserve values when keys agree. For example, when calling
map:merge((map:entry(0, "red"), (map:entry(1, "green"), map:entry(1,"blue")))
I would like to get back something like
map { 0: "red", 1: ("green", "blue") }The default (W3C) behavior is to drop "green" in favor of "blue".
Is there a simple way to accomplish this? I realize the above example is mixing types so presumably a solution would have all values as sets.
Thanks, Ron
Thanks, Christian. I was able to adapt your second suggestion to my needs as follows:
let $keys := distinct-values( for $trial in db:open('CTGov')/clinical_study return distinct-values($trial/id_info/org_study_id union $trial/id_info/secondary_id union $trial/acronym) )
let $map2 := map:merge( for $key in $keys let $value := for $trial in db:open('CTGov')/clinical_study[id_info/org_study_id = $key or id_info/secondary_id = $key or acronym = $key] return $trial return map { $key : $value } )
The code is fairly efficient, creating the map from 200,000 clinicaltrial.gov trials in about 1 minute.
Any chance this could be made an option of map:merge? Doing it in Java would be faster and more elegant.
Best, Ron
On December 29, 2015 at 3:12:28 AM, Christian Grün (christian.gruen@gmail.com) wrote:
Try this:
let $maps := ( map:entry(0, "red"), map:entry(1, "green"), map:entry(1, "blue") ) return map:merge( for $map in $maps for $key in map:keys($map) group by $key return map { $key : $map ! .($key) } )
This is an equivalent, possibly better readable, solution:
let $maps := ( map:entry(0, "red"), map:entry(1, "green"), map:entry(1, "blue") ) let $keys := distinct-values( for $map in $maps return map:keys($map) ) return map:merge( for $key in $keys let $value := for $map in $maps return $map($key) return map { $key : $value } )
On Wed, Dec 23, 2015 at 11:04 PM, Ron Katriel rkatriel@mdsol.com wrote:
Hi,
I am using map:merge to construct a map from smaller maps and would like to preserve values when keys agree. For example, when calling
map:merge((map:entry(0, "red"), (map:entry(1, "green"), map:entry(1, "blue")))
I would like to get back something like
map { 0: "red", 1: ("green", "blue") }
The default (W3C) behavior is to drop "green" in favor of "blue".
Is there a simple way to accomplish this? I realize the above example is mixing types so presumably a solution would have all values as sets.
Thanks, Ron
Any chance this could be made an option of map:merge? Doing it in Java would be faster and more elegant.
It will be too late for XQuery 3.1, but feel free to motivate such enhancements in the W3 Bug Tracker [1].
Christian
[1] https://www.w3.org/Bugs/Public/
Best, Ron
On December 29, 2015 at 3:12:28 AM, Christian Grün (christian.gruen@gmail.com) wrote:
Try this:
let $maps := ( map:entry(0, "red"), map:entry(1, "green"), map:entry(1, "blue") ) return map:merge( for $map in $maps for $key in map:keys($map) group by $key return map { $key : $map ! .($key) } )
This is an equivalent, possibly better readable, solution:
let $maps := ( map:entry(0, "red"), map:entry(1, "green"), map:entry(1, "blue") ) let $keys := distinct-values( for $map in $maps return map:keys($map) ) return map:merge( for $key in $keys let $value := for $map in $maps return $map($key) return map { $key : $value } )
On Wed, Dec 23, 2015 at 11:04 PM, Ron Katriel rkatriel@mdsol.com wrote:
Hi,
I am using map:merge to construct a map from smaller maps and would like to preserve values when keys agree. For example, when calling
map:merge((map:entry(0, "red"), (map:entry(1, "green"), map:entry(1, "blue")))
I would like to get back something like
map { 0: "red", 1: ("green", "blue") }
The default (W3C) behavior is to drop "green" in favor of "blue".
Is there a simple way to accomplish this? I realize the above example is mixing types so presumably a solution would have all values as sets.
Thanks, Ron
Done (Bug 29353).
Thanks, Ron
On December 30, 2015 at 9:57:00 AM, Christian Grün (christian.gruen@gmail.com) wrote:
Any chance this could be made an option of map:merge? Doing it in Java would be faster and more elegant.
It will be too late for XQuery 3.1, but feel free to motivate such enhancements in the W3 Bug Tracker [1].
Christian
[1] https://www.w3.org/Bugs/Public/
Best, Ron
On December 29, 2015 at 3:12:28 AM, Christian Grün (christian.gruen@gmail.com) wrote:
Try this:
let $maps := ( map:entry(0, "red"), map:entry(1, "green"), map:entry(1, "blue") ) return map:merge( for $map in $maps for $key in map:keys($map) group by $key return map { $key : $map ! .($key) } )
This is an equivalent, possibly better readable, solution:
let $maps := ( map:entry(0, "red"), map:entry(1, "green"), map:entry(1, "blue") ) let $keys := distinct-values( for $map in $maps return map:keys($map) ) return map:merge( for $key in $keys let $value := for $map in $maps return $map($key) return map { $key : $value } )
On Wed, Dec 23, 2015 at 11:04 PM, Ron Katriel rkatriel@mdsol.com wrote:
Hi,
I am using map:merge to construct a map from smaller maps and would like to preserve values when keys agree. For example, when calling
map:merge((map:entry(0, "red"), (map:entry(1, "green"), map:entry(1, "blue")))
I would like to get back something like
map { 0: "red", 1: ("green", "blue") }
The default (W3C) behavior is to drop "green" in favor of "blue".
Is there a simple way to accomplish this? I realize the above example is mixing types so presumably a solution would have all values as sets.
Thanks, Ron
A last hint: Performance is mostly a matter of how maps are implemented in a particular XQuery processor. You may be able to speed up your query if you only iterate over all nodes only once:
let $maps := for $trial in db:open('CTGov')/clinical_study return ( map:entry(string($trial/id_info/org_study_id), $trial), map:entry(string($trial/id_info/secondary_id), $trial), map:entry(string($trial/acronym), $trial) ) return map:merge( for $map in $maps for $key in map:keys($map) group by $key let $value := ($map ! .($key))/self::node() return map { $key : $value } )
If map keys are converted to strings, lookup will be a bit faster. Next, the "/self::node()" step removes potential duplicate nodes (just skip it if the IDs are unique assigned to a single "clinical_study" element are distinct).
On Wed, Dec 30, 2015 at 7:13 PM, Ron Katriel rkatriel@mdsol.com wrote:
Done (Bug 29353).
Thanks, Ron
On December 30, 2015 at 9:57:00 AM, Christian Grün (christian.gruen@gmail.com) wrote:
Any chance this could be made an option of map:merge? Doing it in Java would be faster and more elegant.
It will be too late for XQuery 3.1, but feel free to motivate such enhancements in the W3 Bug Tracker [1].
Christian
[1] https://www.w3.org/Bugs/Public/
Best, Ron
On December 29, 2015 at 3:12:28 AM, Christian Grün (christian.gruen@gmail.com) wrote:
Try this:
let $maps := ( map:entry(0, "red"), map:entry(1, "green"), map:entry(1, "blue") ) return map:merge( for $map in $maps for $key in map:keys($map) group by $key return map { $key : $map ! .($key) } )
This is an equivalent, possibly better readable, solution:
let $maps := ( map:entry(0, "red"), map:entry(1, "green"), map:entry(1, "blue") ) let $keys := distinct-values( for $map in $maps return map:keys($map) ) return map:merge( for $key in $keys let $value := for $map in $maps return $map($key) return map { $key : $value } )
On Wed, Dec 23, 2015 at 11:04 PM, Ron Katriel rkatriel@mdsol.com wrote:
Hi,
I am using map:merge to construct a map from smaller maps and would like to preserve values when keys agree. For example, when calling
map:merge((map:entry(0, "red"), (map:entry(1, "green"), map:entry(1, "blue")))
I would like to get back something like
map { 0: "red", 1: ("green", "blue") }
The default (W3C) behavior is to drop "green" in favor of "blue".
Is there a simple way to accomplish this? I realize the above example is mixing types so presumably a solution would have all values as sets.
Thanks, Ron
Thanks, Christian. Much appreciated advice. The only change needed was due to the fact that trials often have multiple ids of the same type (e.g., secondary_id) or empty ids (acronym is optional). Also, ids are sometimes actually lists of ids separated by commas (poor coding practice by sponsors). So the working code looks as follows:
let $maps := for $trial in db:open('CTGov')/clinical_study return ( for $id in $trial/id_info/org_study_id for $t in tokenize($id, ',') return map:entry(functx:trim($t), $trial), for $id in $trial/id_info/secondary_id for $t in tokenize($id, ',') return map:entry(functx:trim($t), $trial), for $id in $trial/acronym for $t in tokenize($id, ',') return map:entry(functx:trim($t), $trial) )
The new code completes in 10 seconds, a major improvement!
Best, Ron
On December 30, 2015 at 1:23:44 PM, Christian Grün (christian.gruen@gmail.com) wrote:
A last hint: Performance is mostly a matter of how maps are implemented in a particular XQuery processor. You may be able to speed up your query if you only iterate over all nodes only once:
let $maps := for $trial in db:open('CTGov')/clinical_study return ( map:entry(string($trial/id_info/org_study_id), $trial), map:entry(string($trial/id_info/secondary_id), $trial), map:entry(string($trial/acronym), $trial) ) return map:merge( for $map in $maps for $key in map:keys($map) group by $key let $value := ($map ! .($key))/self::node() return map { $key : $value } )
If map keys are converted to strings, lookup will be a bit faster. Next, the "/self::node()" step removes potential duplicate nodes (just skip it if the IDs are unique assigned to a single "clinical_study" element are distinct).
On Wed, Dec 30, 2015 at 7:13 PM, Ron Katriel rkatriel@mdsol.com wrote:
Done (Bug 29353).
Thanks, Ron
On December 30, 2015 at 9:57:00 AM, Christian Grün (christian.gruen@gmail.com) wrote:
Any chance this could be made an option of map:merge? Doing it in Java would be faster and more elegant.
It will be too late for XQuery 3.1, but feel free to motivate such enhancements in the W3 Bug Tracker [1].
Christian
[1] https://www.w3.org/Bugs/Public/
Best, Ron
On December 29, 2015 at 3:12:28 AM, Christian Grün (christian.gruen@gmail.com) wrote:
Try this:
let $maps := ( map:entry(0, "red"), map:entry(1, "green"), map:entry(1, "blue") ) return map:merge( for $map in $maps for $key in map:keys($map) group by $key return map { $key : $map ! .($key) } )
This is an equivalent, possibly better readable, solution:
let $maps := ( map:entry(0, "red"), map:entry(1, "green"), map:entry(1, "blue") ) let $keys := distinct-values( for $map in $maps return map:keys($map) ) return map:merge( for $key in $keys let $value := for $map in $maps return $map($key) return map { $key : $value } )
On Wed, Dec 23, 2015 at 11:04 PM, Ron Katriel rkatriel@mdsol.com wrote:
Hi,
I am using map:merge to construct a map from smaller maps and would like to preserve values when keys agree. For example, when calling
map:merge((map:entry(0, "red"), (map:entry(1, "green"), map:entry(1, "blue")))
I would like to get back something like
map { 0: "red", 1: ("green", "blue") }
The default (W3C) behavior is to drop "green" in favor of "blue".
Is there a simple way to accomplish this? I realize the above example is mixing types so presumably a solution would have all values as sets.
Thanks, Ron
Do you have a timeframe for the metadata properties? I'm very interested :-).
On Wed, Dec 23, 2015 at 9:19 AM, Christian Grün christian.gruen@gmail.com wrote:
Hi Laurent,
I discovered BaseX recently and I find it really powerfull.
Unfortunately, I
read that versioning was not supported out of the box in 2014 [1]. Is it still the case ? Is there no simple workaround ?
BaseX does not come with an out-of-the-box solution for versioning XML documents, but there are many ways to realize this via XQuery or the existing commands. You could e.g. attach timestamps in the database file paths or update information in an additional XML meta file with each request. We have also started defining document metadata properties [1], but this is still work in progress.
A simple way to achieve such a behaviour would be to be able to index a
XML
resource in BaseX with some additional meta information such as an ID
and a
timestamp, and then offer the possibility to use these meta information
in
an XQuery to filter resources.
Is it possible with BaseX 8.3 ?
This is absolutely possible. I don’t know how much time you have already spent with XQuery, but could check out our Wiki articles on XQuery Update [2] and the Database Module [3].
Hope this helps, Christian
[1] https://github.com/BaseXdb/basex/issues/988 [2] http://docs.basex.org/wiki/XQuery_Update [3] http://docs.basex.org/wiki/Database_Module
On Wed, Dec 23, 2015 at 2:18 PM, Laurent Pellegrino laurent.pellegrino@activeeon.com wrote:
Hello all,
I discovered BaseX recently and I find it really powerfull.
Unfortunately, I
read that versioning was not supported out of the box in 2014 [1]. Is it still the case ? Is there no simple workaround ?
My usecase is the following. I have thousands of XML files which are
indexed
using BaseX in a specific database, lets say "mydb". At some point of
time,
a user may want to add a new XML file which is a slightly modified
version
of one already indexed by BaseX.
I would like to be able to:
- store this new XML resource in "mydb" database without loosing the
XML
from which it is issued
- to retrieve the latest version or a previous one.
- filter resources based on the latest version
A simple way to achieve such a behaviour would be to be able to index a
XML
resource in BaseX with some additional meta information such as an ID
and a
timestamp, and then offer the possibility to use these meta information
in
an XQuery to filter resources.
Is it possible with BaseX 8.3 ?
I am looking for a solution that does not a require another database.
[1]
https://mailman.uni-konstanz.de/pipermail/basex-talk/2014-March/006535.html
Kind Regards,
Laurent Pellegrino
Dear France,
Right now, I cannot give you a fixed timeframe. I guess the introduction of metadata properties may depend on the availability of sponsors. However, we could possibly take advantage of its introduction in one of our own commercial projects as well, so this could be the reason for tackling it in spring or summer 2016 (but I cannot promise anything ;).
Christian ________________________________
On Thu, Dec 31, 2015 at 5:28 AM, France Baril france.baril@architextus.com wrote:
Do you have a timeframe for the metadata properties? I'm very interested :-).
On Wed, Dec 23, 2015 at 9:19 AM, Christian Grün christian.gruen@gmail.com wrote:
Hi Laurent,
I discovered BaseX recently and I find it really powerfull. Unfortunately, I read that versioning was not supported out of the box in 2014 [1]. Is it still the case ? Is there no simple workaround ?
BaseX does not come with an out-of-the-box solution for versioning XML documents, but there are many ways to realize this via XQuery or the existing commands. You could e.g. attach timestamps in the database file paths or update information in an additional XML meta file with each request. We have also started defining document metadata properties [1], but this is still work in progress.
A simple way to achieve such a behaviour would be to be able to index a XML resource in BaseX with some additional meta information such as an ID and a timestamp, and then offer the possibility to use these meta information in an XQuery to filter resources.
Is it possible with BaseX 8.3 ?
This is absolutely possible. I don’t know how much time you have already spent with XQuery, but could check out our Wiki articles on XQuery Update [2] and the Database Module [3].
Hope this helps, Christian
[1] https://github.com/BaseXdb/basex/issues/988 [2] http://docs.basex.org/wiki/XQuery_Update [3] http://docs.basex.org/wiki/Database_Module
On Wed, Dec 23, 2015 at 2:18 PM, Laurent Pellegrino laurent.pellegrino@activeeon.com wrote:
Hello all,
I discovered BaseX recently and I find it really powerfull. Unfortunately, I read that versioning was not supported out of the box in 2014 [1]. Is it still the case ? Is there no simple workaround ?
My usecase is the following. I have thousands of XML files which are indexed using BaseX in a specific database, lets say "mydb". At some point of time, a user may want to add a new XML file which is a slightly modified version of one already indexed by BaseX.
I would like to be able to:
- store this new XML resource in "mydb" database without loosing the
XML from which it is issued
- to retrieve the latest version or a previous one.
- filter resources based on the latest version
A simple way to achieve such a behaviour would be to be able to index a XML resource in BaseX with some additional meta information such as an ID and a timestamp, and then offer the possibility to use these meta information in an XQuery to filter resources.
Is it possible with BaseX 8.3 ?
I am looking for a solution that does not a require another database.
[1]
https://mailman.uni-konstanz.de/pipermail/basex-talk/2014-March/006535.html
Kind Regards,
Laurent Pellegrino
-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com
I'm not able to sponsor anything now. My biggest commercial project is coming to an end. I'm working on smaller projects, which means smaller budgets. I'm also working on 2 volunteer gigs, which means no budget at all.
When I hook another big project, that might change.
By the way, I'm using BaseX to transform content in 303 languages and dialects and they all work. I'm impressed. Vive unicode!
I'm using BaseX for as many projects as I can. I really love the product. My shopping list for future feature would be:
- *Metadata* (mostly to handle work processes: status, version, work assignment) - *The ability to search for files based on values that are actually provided in the xml schema without having to resolve them in content* I currently keep the authors' files and the files used for transformations in 2 separate databases. That's a lot of duplication and keeping both databases in synch is a headache. Transformations are applied to values provided by the schema, so there is no way around this. I can't have @class in the authoring environment, but I require them for transformations and publishing. - *Indexed tokens *for better performance, and even when the tokens are values set in the schema (see previous point). - *The ability to catch changes from webDAV save operations in xquery*. For example, if I could catch operations performed on the database, I could run a process that adds the schema @class values and synch up the publishing/transformation database with the authors' database with each change. I could also delete files in both databases at once. That would limit the headache from the 2nd point. Currently each webDAV operation leaves me with out of synch databases. And moving away from webDAV isn't possible just yet.
I know that as a non-sponsor, I can't push these through right now, but I thought it'd be useful to explain where I'm coming from. Most of my projects use DITA in an authoring environment where I can't just resolve the schema items at import, so these are recurring issues for me. Maybe at some point I can round up enough DITA users around BaseX to get someone to sponsor the shopping list.
Have a great 2016!
France
On Thu, Dec 31, 2015 at 7:20 AM, Christian Grün christian.gruen@gmail.com wrote:
Dear France,
Right now, I cannot give you a fixed timeframe. I guess the introduction of metadata properties may depend on the availability of sponsors. However, we could possibly take advantage of its introduction in one of our own commercial projects as well, so this could be the reason for tackling it in spring or summer 2016 (but I cannot promise anything ;).
Christian ________________________________
On Thu, Dec 31, 2015 at 5:28 AM, France Baril france.baril@architextus.com wrote:
Do you have a timeframe for the metadata properties? I'm very interested :-).
On Wed, Dec 23, 2015 at 9:19 AM, Christian Grün <
christian.gruen@gmail.com>
wrote:
Hi Laurent,
I discovered BaseX recently and I find it really powerfull. Unfortunately, I read that versioning was not supported out of the box in 2014 [1]. Is
it
still the case ? Is there no simple workaround ?
BaseX does not come with an out-of-the-box solution for versioning XML documents, but there are many ways to realize this via XQuery or the existing commands. You could e.g. attach timestamps in the database file paths or update information in an additional XML meta file with each request. We have also started defining document metadata properties [1], but this is still work in progress.
A simple way to achieve such a behaviour would be to be able to index
a
XML resource in BaseX with some additional meta information such as an ID and a timestamp, and then offer the possibility to use these meta
information
in an XQuery to filter resources.
Is it possible with BaseX 8.3 ?
This is absolutely possible. I don’t know how much time you have already spent with XQuery, but could check out our Wiki articles on XQuery Update [2] and the Database Module [3].
Hope this helps, Christian
[1] https://github.com/BaseXdb/basex/issues/988 [2] http://docs.basex.org/wiki/XQuery_Update [3] http://docs.basex.org/wiki/Database_Module
On Wed, Dec 23, 2015 at 2:18 PM, Laurent Pellegrino laurent.pellegrino@activeeon.com wrote:
Hello all,
I discovered BaseX recently and I find it really powerfull. Unfortunately, I read that versioning was not supported out of the box in 2014 [1]. Is
it
still the case ? Is there no simple workaround ?
My usecase is the following. I have thousands of XML files which are indexed using BaseX in a specific database, lets say "mydb". At some point of time, a user may want to add a new XML file which is a slightly modified version of one already indexed by BaseX.
I would like to be able to:
- store this new XML resource in "mydb" database without loosing the
XML from which it is issued
- to retrieve the latest version or a previous one.
- filter resources based on the latest version
A simple way to achieve such a behaviour would be to be able to index
a
XML resource in BaseX with some additional meta information such as an ID and a timestamp, and then offer the possibility to use these meta
information
in an XQuery to filter resources.
Is it possible with BaseX 8.3 ?
I am looking for a solution that does not a require another database.
[1]
https://mailman.uni-konstanz.de/pipermail/basex-talk/2014-March/006535.html
Kind Regards,
Laurent Pellegrino
-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
France Baril -
Laurent Pellegrino -
Ron Katriel