Versioning
Wednesday, 23 December 2015 · 12 messages · last reply 31 Dec 2015
LP
Laurent Pellegrino23 Dec 2015 14:18 #
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
CG
Christian Grün23 Dec 2015 15:19 #
Hi Laurent,
Quoted text · Laurent Pellegrino · 3 lines
> 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.
Quoted text · Laurent Pellegrino · 6 lines
> 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
Quoted text · Laurent Pellegrino · 36 lines
On Wed, Dec 23, 2015 at 2:18 PM, Laurent Pellegrino <laurent.pellegrino at 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 >
RK
Ron Katriel24 Dec 2015 00:04 #
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
CG
Christian Grün29 Dec 2015 09:12 #
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 }
)Quoted text · Ron Katriel · 21 lines
On Wed, Dec 23, 2015 at 11:04 PM, Ron Katriel <rkatriel at 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 >
CG
Quoted text · Ron Katriel · 2 lines
> 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/
Quoted text · Ron Katriel · 63 lines
> > Best, > Ron > > On December 29, 2015 at 3:12:28 AM, Christian Grün > (christian.gruen at 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 at 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 >>
RK
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,
RonQuoted text · Christian Grün (christian.gruen at gmail.com) · 1 line
On December 29, 2015 at 3:12:28 AM, Christian Grün (christian.gruen at 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 }
)Quoted text · Ron Katriel · 21 lines
On Wed, Dec 23, 2015 at 11:04 PM, Ron Katriel <rkatriel at 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 >
CG
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).
Quoted text · Ron Katriel · 84 lines
On Wed, Dec 30, 2015 at 7:13 PM, Ron Katriel <rkatriel at mdsol.com> wrote: > Done (Bug 29353). > > Thanks, > Ron > > On December 30, 2015 at 9:57:00 AM, Christian Grün > (christian.gruen at 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 at 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 at 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 >>>
RK
Done (Bug 29353).
Thanks,
Ron
Quoted text · Christian Grün (christian.gruen at gmail.com) · 3 lines
On December 30, 2015 at 9:57:00 AM, Christian Grün (christian.gruen at 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/
Quoted text · Christian Grün · 63 lines
> > Best, > Ron > > On December 29, 2015 at 3:12:28 AM, Christian Grün > (christian.gruen at 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 at 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 >>
RK
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
Quoted text · Christian Grün (christian.gruen at gmail.com) · 1 line
On December 30, 2015 at 1:23:44 PM, Christian Grün (christian.gruen at 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).
Quoted text · Ron Katriel · 84 lines
On Wed, Dec 30, 2015 at 7:13 PM, Ron Katriel <rkatriel at mdsol.com> wrote: > Done (Bug 29353). > > Thanks, > Ron > > On December 30, 2015 at 9:57:00 AM, Christian Grün > (christian.gruen at 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 at 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 at 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 >>>
FB
Do you have a timeframe for the metadata properties? I'm very interested :-).
Quoted text · Christian Grün · 85 lines
On Wed, Dec 23, 2015 at 9:19 AM, Christian Grün <christian.gruen at 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 at 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 at architextus.com
CG
Christian Grün31 Dec 2015 13:20 #
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
Quoted text · France Baril · 98 lines
On Thu, Dec 31, 2015 at 5:28 AM, France Baril <france.baril at 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 at 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 at 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 at architextus.com
FB
France Baril31 Dec 2015 19:55 #
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
Quoted text · Christian Grün · 121 lines
On Thu, Dec 31, 2015 at 7:20 AM, Christian Grün <christian.gruen at 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 at 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 at 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 at 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 at architextus.com >
--
France Baril
Architecte documentaire / Documentation architect
france.baril at architextus.com
Written for BaseX 8.3. BaseX may have changed since: please check the current documentation.
⚡Generated with XQuery