Christian, all,
The new "combined" packaging option ( https://github.com/BaseXdb/basex/issues/1413) seems like an interesting enhancement.
I have been working on my first BaseX repository module/package (though unfortunately I am not yet fluent in Java). It is working perfectly so far, but I wanted to be sure I was going about it correctly because it still seems a little like magic to me. I am also wondering whether this new feature is something I might want to take advantage of.
The module (https://github.com/timathom/basex-rdf) uses Günther Rademacher's REx Parser Generator[1] to create a Java parser for the RDF TriG/Turtle syntax[2], using the BaseX extension function option.
Following the BaseX documentation[3], I have created a XAR package that includes the JAR file and an XQuery wrapper. The wrapper calls the function exposed by the Java module (import module namespace trig = "org.basex.modules.rdf.TriG";) and then processes the raw parse tree, overlaying some additional abstractions (I confess that I cheated and used XSLT for most of the processing functionality).
Because of the built-in BaseX extension function, this approach seems different from a straightforward "combined" module approach, but, again, I wanted to ask whether the way I'm doing this seems correct.
Thanks in advance.
Tim
[1] http://www.bottlecaps.de/rex/ [2] https://www.w3.org/TR/trig/ [3] docs.basex.org/wiki/Repository
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
Hi Tim,
Thanks for the link to your RDF library.
I’m glad to hear that the new packaging mechanism has already found watchers. I have just uploaded a new snapshot, and I would be glad to have your feedback as first tester ;)
but I wanted to be sure I was going about it correctly because it still seems a little like magic to me. I am also wondering whether this new feature is something I might want to take advantage of.
I haven’t run any queries yet with your module, but the package structure looks fine.
Our experience over the years is that the EXPath packaging mechanism is a bit difficult to understand, and not as portable as we believe it could be. It would be nice, for example, if a package could be distributed without implementation-specific details inside. But it’s always easy to complain, and it takes a lot of time to get things going.
For our own use cases, the simple packaging mechanism is just good enough. It would be nice if we could add some versioning support in the future, though.
Cheers Christian
The module (https://github.com/timathom/basex-rdf) uses Günther Rademacher's REx Parser Generator[1] to create a Java parser for the RDF TriG/Turtle syntax[2], using the BaseX extension function option.
Following the BaseX documentation[3], I have created a XAR package that includes the JAR file and an XQuery wrapper. The wrapper calls the function exposed by the Java module (import module namespace trig = "org.basex.modules.rdf.TriG";) and then processes the raw parse tree, overlaying some additional abstractions (I confess that I cheated and used XSLT for most of the processing functionality).
Because of the built-in BaseX extension function, this approach seems different from a straightforward "combined" module approach, but, again, I wanted to ask whether the way I'm doing this seems correct.
Thanks in advance.
Tim
[1] http://www.bottlecaps.de/rex/ [2] https://www.w3.org/TR/trig/ [3] docs.basex.org/wiki/Repository
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
Thanks, Christian. I had a quick question about the expath-pkg.xml file (attached). I have two XSLT files that I want to list separately, along with listing Saxon-HE (version 9.8.x) as a dependency. However, when I add a second dependency element and try to import the package, I get an error:
[bxerr:BXRE0009] Package version is not supported.
Looking at the EXPath package schema[1], it seems as though this should be valid (the dependency element should be repeatable).
Tim
[1] http://expath.org/spec/pkg#structure
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
On Fri, Oct 20, 2017 at 2:25 PM, Christian Grün christian.gruen@gmail.com wrote:
Hi Tim,
Thanks for the link to your RDF library.
I’m glad to hear that the new packaging mechanism has already found watchers. I have just uploaded a new snapshot, and I would be glad to have your feedback as first tester ;)
but I wanted to be sure I was going about it correctly because it still seems a little like magic to me. I am also wondering whether this new feature is something I might want to take advantage of.
I haven’t run any queries yet with your module, but the package structure looks fine.
Our experience over the years is that the EXPath packaging mechanism is a bit difficult to understand, and not as portable as we believe it could be. It would be nice, for example, if a package could be distributed without implementation-specific details inside. But it’s always easy to complain, and it takes a lot of time to get things going.
For our own use cases, the simple packaging mechanism is just good enough. It would be nice if we could add some versioning support in the future, though.
Cheers Christian
The module (https://github.com/timathom/basex-rdf) uses Günther
Rademacher's
REx Parser Generator[1] to create a Java parser for the RDF TriG/Turtle syntax[2], using the BaseX extension function option.
Following the BaseX documentation[3], I have created a XAR package that includes the JAR file and an XQuery wrapper. The wrapper calls the
function
exposed by the Java module (import module namespace trig = "org.basex.modules.rdf.TriG";) and then processes the raw parse tree, overlaying some additional abstractions (I confess that I cheated and
used
XSLT for most of the processing functionality).
Because of the built-in BaseX extension function, this approach seems different from a straightforward "combined" module approach, but, again,
I
wanted to ask whether the way I'm doing this seems correct.
Thanks in advance.
Tim
[1] http://www.bottlecaps.de/rex/ [2] https://www.w3.org/TR/trig/ [3] docs.basex.org/wiki/Repository
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
Hi Tim,
I’ll have a look soon, probably tomorrow. Out of interest: Have you been successful using our combined approach?
Best, Christian
On Tue, Oct 24, 2017 at 4:16 PM, Tim Thompson timathom@gmail.com wrote:
Thanks, Christian. I had a quick question about the expath-pkg.xml file (attached). I have two XSLT files that I want to list separately, along with listing Saxon-HE (version 9.8.x) as a dependency. However, when I add a second dependency element and try to import the package, I get an error:
[bxerr:BXRE0009] Package version is not supported.
Looking at the EXPath package schema[1], it seems as though this should be valid (the dependency element should be repeatable).
Tim
[1] http://expath.org/spec/pkg#structure
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
On Fri, Oct 20, 2017 at 2:25 PM, Christian Grün christian.gruen@gmail.com wrote:
Hi Tim,
Thanks for the link to your RDF library.
I’m glad to hear that the new packaging mechanism has already found watchers. I have just uploaded a new snapshot, and I would be glad to have your feedback as first tester ;)
but I wanted to be sure I was going about it correctly because it still seems a little like magic to me. I am also wondering whether this new feature is something I might want to take advantage of.
I haven’t run any queries yet with your module, but the package structure looks fine.
Our experience over the years is that the EXPath packaging mechanism is a bit difficult to understand, and not as portable as we believe it could be. It would be nice, for example, if a package could be distributed without implementation-specific details inside. But it’s always easy to complain, and it takes a lot of time to get things going.
For our own use cases, the simple packaging mechanism is just good enough. It would be nice if we could add some versioning support in the future, though.
Cheers Christian
The module (https://github.com/timathom/basex-rdf) uses Günther Rademacher's REx Parser Generator[1] to create a Java parser for the RDF TriG/Turtle syntax[2], using the BaseX extension function option.
Following the BaseX documentation[3], I have created a XAR package that includes the JAR file and an XQuery wrapper. The wrapper calls the function exposed by the Java module (import module namespace trig = "org.basex.modules.rdf.TriG";) and then processes the raw parse tree, overlaying some additional abstractions (I confess that I cheated and used XSLT for most of the processing functionality).
Because of the built-in BaseX extension function, this approach seems different from a straightforward "combined" module approach, but, again, I wanted to ask whether the way I'm doing this seems correct.
Thanks in advance.
Tim
[1] http://www.bottlecaps.de/rex/ [2] https://www.w3.org/TR/trig/ [3] docs.basex.org/wiki/Repository
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
Hi, Christian,
I had a chance to try out the combined module feature this afternoon. Copies of the combined JAR file and related files are here: https://github.com/timathom/basex-rdf.
I was able to create a basic module, but I did run into a few hiccups along the way:
1. From my XQuery module, I want to call a pair of XSLT stylesheets, so I tried adding these to the JAR as well. However, when I import the combined JAR file, the XSLT files are not copied over. If I copy them manually into the BaseXRepo folder, then it works. 2. In my previous experiments with the EXPath repo approach, I was able to import the Java module while also defining a separate namespace for the XQuery wrapper module itself. Thus, I was able to define additional XQuery functions in the namespace of the wrapper module. With the new combined approach, however, it seems that each XQuery function must correspond to a Java function, and the namespaces must match (e.g., " http://basex.org/modules/rdf/Triples" and "java:org.basex.modules.rdf.Triples"). I had to remove my additional XQuery functions from the wrapper because BaseX was throwing an error that the functions were not Java functions.
Just let me know if I can provide any other feedback that would be helpful.
Best, Tim
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
On Tue, Oct 24, 2017 at 12:36 PM, Christian Grün christian.gruen@gmail.com wrote:
Hi Tim,
I’ll have a look soon, probably tomorrow. Out of interest: Have you been successful using our combined approach?
Best, Christian
On Tue, Oct 24, 2017 at 4:16 PM, Tim Thompson timathom@gmail.com wrote:
Thanks, Christian. I had a quick question about the expath-pkg.xml file (attached). I have two XSLT files that I want to list separately, along
with
listing Saxon-HE (version 9.8.x) as a dependency. However, when I add a second dependency element and try to import the package, I get an error:
[bxerr:BXRE0009] Package version is not supported.
Looking at the EXPath package schema[1], it seems as though this should
be
valid (the dependency element should be repeatable).
Tim
[1] http://expath.org/spec/pkg#structure
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
On Fri, Oct 20, 2017 at 2:25 PM, Christian Grün <
christian.gruen@gmail.com>
wrote:
Hi Tim,
Thanks for the link to your RDF library.
I’m glad to hear that the new packaging mechanism has already found watchers. I have just uploaded a new snapshot, and I would be glad to have your feedback as first tester ;)
but I wanted to be sure I was going about it correctly because it
still
seems a little like magic to me. I am also wondering whether this new feature is something I might want to take advantage of.
I haven’t run any queries yet with your module, but the package structure looks fine.
Our experience over the years is that the EXPath packaging mechanism is a bit difficult to understand, and not as portable as we believe it could be. It would be nice, for example, if a package could be distributed without implementation-specific details inside. But it’s always easy to complain, and it takes a lot of time to get things going.
For our own use cases, the simple packaging mechanism is just good enough. It would be nice if we could add some versioning support in the future, though.
Cheers Christian
The module (https://github.com/timathom/basex-rdf) uses Günther Rademacher's REx Parser Generator[1] to create a Java parser for the RDF
TriG/Turtle
syntax[2], using the BaseX extension function option.
Following the BaseX documentation[3], I have created a XAR package
that
includes the JAR file and an XQuery wrapper. The wrapper calls the function exposed by the Java module (import module namespace trig = "org.basex.modules.rdf.TriG";) and then processes the raw parse tree, overlaying some additional abstractions (I confess that I cheated and used XSLT for most of the processing functionality).
Because of the built-in BaseX extension function, this approach seems different from a straightforward "combined" module approach, but,
again,
I wanted to ask whether the way I'm doing this seems correct.
Thanks in advance.
Tim
[1] http://www.bottlecaps.de/rex/ [2] https://www.w3.org/TR/trig/ [3] docs.basex.org/wiki/Repository
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
One more related question. When I try to use the BaseX fetch:text function to retrieve an RDF text file and pass it to my combined module parser function, I get an error (in the the latest BaseX snapshot: beta a48337f): Function parseTrigDoc(xs:string) cannot be called with (xs:string). However, if I change from fetch:text to unparsed-text, I am able to retrieve the file and parse it successfully. Is it possible to use fetch:text here[1]?
Thanks again.
Tim
[1] https://github.com/metadataframes/basex-rdf/blob/master/src/triples.xq
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
On Tue, Oct 24, 2017 at 5:25 PM, Tim Thompson timathom@gmail.com wrote:
Hi, Christian,
I had a chance to try out the combined module feature this afternoon. Copies of the combined JAR file and related files are here: https://github.com/timathom/basex-rdf.
I was able to create a basic module, but I did run into a few hiccups along the way:
- From my XQuery module, I want to call a pair of XSLT stylesheets,
so I tried adding these to the JAR as well. However, when I import the combined JAR file, the XSLT files are not copied over. If I copy them manually into the BaseXRepo folder, then it works. 2. In my previous experiments with the EXPath repo approach, I was able to import the Java module while also defining a separate namespace for the XQuery wrapper module itself. Thus, I was able to define additional XQuery functions in the namespace of the wrapper module. With the new combined approach, however, it seems that each XQuery function must correspond to a Java function, and the namespaces must match (e.g., " http://basex.org/modules/rdf/Triples http://basex.org/modules/rdf/Triples" and "java: org.basex.modules.rdf.Triples"). I had to remove my additional XQuery functions from the wrapper because BaseX was throwing an error that the functions were not Java functions.
Just let me know if I can provide any other feedback that would be helpful.
Best, Tim
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
On Tue, Oct 24, 2017 at 12:36 PM, Christian Grün < christian.gruen@gmail.com> wrote:
Hi Tim,
I’ll have a look soon, probably tomorrow. Out of interest: Have you been successful using our combined approach?
Best, Christian
On Tue, Oct 24, 2017 at 4:16 PM, Tim Thompson timathom@gmail.com wrote:
Thanks, Christian. I had a quick question about the expath-pkg.xml file (attached). I have two XSLT files that I want to list separately, along
with
listing Saxon-HE (version 9.8.x) as a dependency. However, when I add a second dependency element and try to import the package, I get an error:
[bxerr:BXRE0009] Package version is not supported.
Looking at the EXPath package schema[1], it seems as though this should
be
valid (the dependency element should be repeatable).
Tim
[1] http://expath.org/spec/pkg#structure
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
On Fri, Oct 20, 2017 at 2:25 PM, Christian Grün <
christian.gruen@gmail.com>
wrote:
Hi Tim,
Thanks for the link to your RDF library.
I’m glad to hear that the new packaging mechanism has already found watchers. I have just uploaded a new snapshot, and I would be glad to have your feedback as first tester ;)
but I wanted to be sure I was going about it correctly because it
still
seems a little like magic to me. I am also wondering whether this new feature is something I might want to take advantage of.
I haven’t run any queries yet with your module, but the package structure looks fine.
Our experience over the years is that the EXPath packaging mechanism is a bit difficult to understand, and not as portable as we believe it could be. It would be nice, for example, if a package could be distributed without implementation-specific details inside. But it’s always easy to complain, and it takes a lot of time to get things going.
For our own use cases, the simple packaging mechanism is just good enough. It would be nice if we could add some versioning support in the future, though.
Cheers Christian
The module (https://github.com/timathom/basex-rdf) uses Günther Rademacher's REx Parser Generator[1] to create a Java parser for the RDF
TriG/Turtle
syntax[2], using the BaseX extension function option.
Following the BaseX documentation[3], I have created a XAR package
that
includes the JAR file and an XQuery wrapper. The wrapper calls the function exposed by the Java module (import module namespace trig = "org.basex.modules.rdf.TriG";) and then processes the raw parse tree, overlaying some additional abstractions (I confess that I cheated and used XSLT for most of the processing functionality).
Because of the built-in BaseX extension function, this approach seems different from a straightforward "combined" module approach, but,
again,
I wanted to ask whether the way I'm doing this seems correct.
Thanks in advance.
Tim
[1] http://www.bottlecaps.de/rex/ [2] https://www.w3.org/TR/trig/ [3] docs.basex.org/wiki/Repository
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
Hi Tim,
Thanks for the hint, and the intent to create a combined package for your code (our approach seems to be too limited indeed).
Once again my day was shorter than I expected, so I’ll do my best to check out your project tomorrow.
When I try to use the BaseX fetch:text function to retrieve an RDF text file and pass it to my combined module parser function, I get an error (in the the latest BaseX snapshot: beta a48337f): Function parseTrigDoc(xs:string) cannot be called with (xs:string).
My spontaneous guess is that fetch:text returns a “streamable” string (its contents will only be generated if they are requested), and our Java conversion mapping seem not be prepared to handle these types of strings. Actually they should be, so I’ll check how this can be fixed. In the meanwhile, you should be able to work around the restriction by explicitly requesting the string via stream:materialize(fetch:text(...)).
Hope this helps, Christian
[1] http://docs.basex.org/wiki/Fetch_Module#fetch:text [2] http://docs.basex.org/wiki/Streaming_Module
Thanks, I did try stream:materialize, but that didn't seem to help. Regarding the "limitation" of the new combined approach, I think that may actually be a plus. In my case, it forced me to make my code a bit more modular.
Tim
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
On Wed, Oct 25, 2017 at 11:25 AM, Christian Grün christian.gruen@gmail.com wrote:
Hi Tim,
Thanks for the hint, and the intent to create a combined package for your code (our approach seems to be too limited indeed).
Once again my day was shorter than I expected, so I’ll do my best to check out your project tomorrow.
When I try to use the BaseX fetch:text function to retrieve an RDF text file and pass it to my combined module parser function, I get an error (in the the latest BaseX snapshot: beta
a48337f):
Function parseTrigDoc(xs:string) cannot be called with (xs:string).
My spontaneous guess is that fetch:text returns a “streamable” string (its contents will only be generated if they are requested), and our Java conversion mapping seem not be prepared to handle these types of strings. Actually they should be, so I’ll check how this can be fixed. In the meanwhile, you should be able to work around the restriction by explicitly requesting the string via stream:materialize(fetch:text(...)).
Hope this helps, Christian
[1] http://docs.basex.org/wiki/Fetch_Module#fetch:text [2] http://docs.basex.org/wiki/Streaming_Module
Hi Tim,
I have cloned your project again, and I have seen that you have already switched to the combined approach. Good to see that it works! So I think, for now, I won’t go deeper into the EXPath issues that you initially reported (feel free to bug me if you think I should ;-).
I got to the bottom of the 'parseTrigDoc(xs:string) cannot be called with (xs:string)' error. It turned out that streamable strings are based on a different Java class called StrStream (and not Str). Things don’t change if stream:materialize is called, as this function simply caches the result.
I’ll have some thought on how to treat (non-)streamable items identically. For now, you can simply bypass this restriction by using "String" instead of "Str" as arguments in your Java code.
Hope this helps, Christian
On Thu, Oct 26, 2017 at 1:16 AM, Tim Thompson timathom@gmail.com wrote:
Thanks, I did try stream:materialize, but that didn't seem to help. Regarding the "limitation" of the new combined approach, I think that may actually be a plus. In my case, it forced me to make my code a bit more modular.
Tim
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
On Wed, Oct 25, 2017 at 11:25 AM, Christian Grün christian.gruen@gmail.com wrote:
Hi Tim,
Thanks for the hint, and the intent to create a combined package for your code (our approach seems to be too limited indeed).
Once again my day was shorter than I expected, so I’ll do my best to check out your project tomorrow.
When I try to use the BaseX fetch:text function to retrieve an RDF text file and pass it to my combined module parser function, I get an error (in the the latest BaseX snapshot: beta a48337f): Function parseTrigDoc(xs:string) cannot be called with (xs:string).
My spontaneous guess is that fetch:text returns a “streamable” string (its contents will only be generated if they are requested), and our Java conversion mapping seem not be prepared to handle these types of strings. Actually they should be, so I’ll check how this can be fixed. In the meanwhile, you should be able to work around the restriction by explicitly requesting the string via stream:materialize(fetch:text(...)).
Hope this helps, Christian
[1] http://docs.basex.org/wiki/Fetch_Module#fetch:text [2] http://docs.basex.org/wiki/Streaming_Module
Hi Tim,
Not sure if this is your problem here, but I think the xslt element uses <import-uri> rather than <namespace>. e.g
<xslt> <import-uri>http://www.functx.com/functx.xsl</import-uri> <file>functx.xsl</file> </xslt>
/Andy
On 24 October 2017 at 15:16, Tim Thompson timathom@gmail.com wrote:
Thanks, Christian. I had a quick question about the expath-pkg.xml file (attached). I have two XSLT files that I want to list separately, along with listing Saxon-HE (version 9.8.x) as a dependency. However, when I add a second dependency element and try to import the package, I get an error:
[bxerr:BXRE0009] Package version is not supported.
Looking at the EXPath package schema[1], it seems as though this should be valid (the dependency element should be repeatable).
Tim
[1] http://expath.org/spec/pkg#structure
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
On Fri, Oct 20, 2017 at 2:25 PM, Christian Grün <christian.gruen@gmail.com
wrote:
Hi Tim,
Thanks for the link to your RDF library.
I’m glad to hear that the new packaging mechanism has already found watchers. I have just uploaded a new snapshot, and I would be glad to have your feedback as first tester ;)
but I wanted to be sure I was going about it correctly because it still seems a little like magic to me. I am also wondering whether this new feature is something I might want to take advantage of.
I haven’t run any queries yet with your module, but the package structure looks fine.
Our experience over the years is that the EXPath packaging mechanism is a bit difficult to understand, and not as portable as we believe it could be. It would be nice, for example, if a package could be distributed without implementation-specific details inside. But it’s always easy to complain, and it takes a lot of time to get things going.
For our own use cases, the simple packaging mechanism is just good enough. It would be nice if we could add some versioning support in the future, though.
Cheers Christian
The module (https://github.com/timathom/basex-rdf) uses Günther
Rademacher's
REx Parser Generator[1] to create a Java parser for the RDF TriG/Turtle syntax[2], using the BaseX extension function option.
Following the BaseX documentation[3], I have created a XAR package that includes the JAR file and an XQuery wrapper. The wrapper calls the
function
exposed by the Java module (import module namespace trig = "org.basex.modules.rdf.TriG";) and then processes the raw parse tree, overlaying some additional abstractions (I confess that I cheated and
used
XSLT for most of the processing functionality).
Because of the built-in BaseX extension function, this approach seems different from a straightforward "combined" module approach, but,
again, I
wanted to ask whether the way I'm doing this seems correct.
Thanks in advance.
Tim
[1] http://www.bottlecaps.de/rex/ [2] https://www.w3.org/TR/trig/ [3] docs.basex.org/wiki/Repository
-- Tim A. Thompson Discovery Metadata Librarian Yale University Library
basex-talk@mailman.uni-konstanz.de
-
Andy Bunce -
Christian Grün -
Tim Thompson