- BaseX-Talk - mailman.uni-konstanz.de

Suggestion about the tutorial examples
by ramon＠patriot.net 09 Oct '10

09 Oct '10

(Newbie alert) I just discovered BaseX. Congratulations and big thanks to the authors and all involved! I have been investigating a LOT of alternatives (programming languages, OSs, toolkits, etc.) and have concluded that the best approach for my application (XML read-only) is to use XPath (plus some XQuery). I have found some introductory examples written in C++ (Xerces) where the authors go through all kinds of complex convolutions to redirect the result of the XPath query to the screen. I hate to state the obvious, but we newbies do not want to send the XML elements to the screen. We rather assign them to some variable. That is the request I have. I think the application "QueryExample" and similar could use some way to assign the retrieved values to a variable. Thanks again! -Ramon (I am not in this mailing list)

1 0

XML catalog support
by Imsieke, Gerrit, le-tex 08 Oct '10

08 Oct '10

Dear BaseX Team, I think I asked this a couple of months ago. We'd like to have XML catalog support when importing files into BaseX. Or do you have another solution for the following issues: 1. - a customer uses XHTML documents enriched with some semantic tagging which is not XHTML markup - they refer to an XHTML DTD though - we need to use the DTD for resolving entities Apart from the fact that it is obnoxious to retrieve the DTDs from W3C (and will be blocked if tried to heavily), the major advntage of catalogs will be that we can point BaseX to a modified XHTML DTD that is stored locally and that allows for the additional semantic tags. => alternative approach: Patch the data to use standard XHTML markup (such as <span class='supersemantic'>). This doesn't seem feasible because too many tools down the processing chain depend on these custom tags. => other approach: resolve all entities prior to import, discard DOCTYPE declaration. We can do that, but it seems second-best to using catalogs and unmodified data. => Patch data to refer to another DOCTYPE stored somewhere on their servers. This is clearly advisable, because these documents aren't XHTML documents. Need to install the necessary infrastructure. Catalogs are still desirable in this scenario 2. Some of their XML files refer to DTDs such as E:\book\book.dtd We need to resolve these to a DTD that is stored on the server where the import takes place. Again, we could patch the data to refer to some DTD stored centrally on one of their corporate HTTP servers Still, in order to speed up parsing, locally stored DTDs are desirable. I remember when I proposed to use Apache XML commons resolver [1,2] that Christian replied you would put it on the wish list. I'm trying to prioritize this issue. (N.B.: it's the same customer who paid someone of your team for solving the base-uri issue...) Gerrit [1] http://xml.apache.org/commons/ [2] mirrored at, e.g., http://apache.easy-webs.de//xml/commons/xml-commons-resolver-1.2.tar.gz -- Gerrit Imsieke Geschäftsführer / Managing Director le-tex publishing services GmbH Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 gerrit.imsieke(a)le-tex.de, http://www.le-tex.de Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930 Geschäftsführer: Gerrit Imsieke, Svea Jelonek, Thomas Schmidt, Dr. Reinhard Vöckler ---------------------------------------------------------------------- Besuchen Sie uns auf der Frankfurter Buchmesse in Halle 4.2, Stand G446. Mehr dazu unter www.le-tex.de/de/buchmesse.html

4 3

database format compatibility from a version to another
by Fabrice Etanchaud 06 Oct '10

06 Oct '10

Dear all at BaseX, could you explain how one can know that database format compatibility is broken from a version to another ? Is it in the version numbering, or do you broadcast the information ? Maybe i dreamed about it, but i cannot find the file module documentation on the website anymore... There is XML with BaseX, and XML without BaseX... Regards

2 1

Bug in Date.diff
by Dave Glick 06 Oct '10

06 Oct '10

I think there might be a bug in Date.diff - it looks like if the number of days are the same, it attempts to directly cast the incoming Item to a Date in order to compare seconds. However, if the incoming Item is actually a string or something else a cast failure will occur. My fix is below: Old code: @Override public int diff(final InputInfo ii, final Item it) throws QueryException { final long d1 = days(); final Date d = (Date) (it.date() ? it : type.e(it, null, ii)); final long d2 = d.days(); if(d1 != d2) return (int) (d1 - d2); return seconds().subtract(((Date) it).seconds()).signum(); } New code: @Override public int diff(final InputInfo ii, final Item it) throws QueryException { final long d1 = days(); final Date d = (Date) (it.date() ? it : type.e(it, null, ii)); final long d2 = d.days(); if(d1 != d2) return (int) (d1 - d2); return seconds().subtract(d.seconds()).signum(); } Dave

3 3

Provide OSGi conformant manifest headers in jar
by erdal.karaca.de＠googlemail.com 04 Oct '10

04 Oct '10

I am using the basex xquery implementation in an OSGi/Eclipse environment and need to provide/add additional manifest headers or wrap the delivered jar. I would like to have those manifest headers automatically included in the build, namely, these would be (minimally): Bundle-SymbolicName: org.basex.api Bundle-Version: 6.2.8.SNAPSHOT Export-Package: javax.xml.xquery, org.basex.api.xqj This way I would just require my components (jars/plugins/bundles) to depend on bundle org.basex.api and would not have to include/manage the basex versions myself...

3 2

Provide OSGi conformant manifest headers in jar
by erdal.karaca.de＠googlemail.com 04 Oct '10

04 Oct '10

sorry, the web contact form is somehow confusing...

1 0

Provide OSGi conformant manifest headers in jar
by erdal.karaca.de＠googlemail.com 04 Oct '10

04 Oct '10

I am using the basex xquery implementation in an OSGi/Eclipse environment and need to provide/add additional manifest headers or wrap the delivered jar. I would like to have those manifest headers automatically included in the build, namely, these would be (minimally): Bundle-SymbolicName: org.basex.api Bundle-Version: 6.2.8.SNAPSHOT Export-Package: javax.xml.xquery, org.basex.api.xqj This way I would just require my components (jars/plugins/bundles) to depend on bundle org.basex.api and would not have to include/manage the basex versions myself...

1 0

Provide OSGi conformant manifest headers in jar
by erdal.karaca.de＠googlemail.com 04 Oct '10

04 Oct '10

I am using the basex xquery implementation in an OSGi/Eclipse environment and need to provide/add additional manifest headers or wrap the delivered jar. I would like to have those manifest headers automatically included in the build, namely, these would be (minimally): Bundle-SymbolicName: org.basex.api Bundle-Version: 6.2.8.SNAPSHOT Export-Package: javax.xml.xquery, org.basex.api.xqj This way I would just require my components (jars/plugins/bundles) to depend on bundle org.basex.api and would not have to include/manage the basex versions myself...

1 0

Re: [basex-talk] Using the REST interface
by Mahender Didwania 04 Oct '10

04 Oct '10

Hi Andreas, Yes, you understood what I wanted, but I did not implement the solution suggested for the reason that there might be dependencies between a given version of basex server (sub-project basex) and the corresponding version of basex-api (sub-project api). I could not simply replace basex-api.jar because, well, basex-api.jar does NOT exist inside of basex-api.zip. On further investigation and while attempting to find a workaround, I noticed that the basex-api.jar is actually split into three different .jars inside basex-api.zip; but those jars (the splitted versions) also package a corresponding dependency each (for xmldb-api, xqj-api and jax-rx, respectively)! I decided to keep things simple and bundled *everything* in one jar, but that broke the runtime. So, I updated my build to include files on as similar a basis as I could (to how you create basex-api.zip) without making the build too complex - so there are a few differences, but it works for me at the moment, so I am going to keep my build simple. In case anyone wants my build config (maven project) to arrive at basex-api.zip, please post your requirement on this mailing list and I can provide you the same. That said, I guess Andreas, that your project is already using a build config to achieve this and would be grateful if you could host that as well as all tags and branches so that these can be anonymously checked out. Thanks for your prompt replies Andreas and Michael, much appreciated. As this is a Uni project, can one hope it has any chances of proper commercial support being provided in case an organization becomes interested? ----- Original Message ----- From: "Andreas Weiler" <andreas.weiler(a)uni-konstanz.de> To: "Mahender Didwania" <mahender(a)didwania.co.uk> Sent: Monday, October 4, 2010 10:20:16 AM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: [basex-talk] Using the REST interface Hi Mahender, you can just extract the BaseX61-api.zip, then add your new BaseX build and change the name of it in the startjaxrx.bat , so the server of the new build is used. I hope i did understand what you are want to do... Kind regards, Andreas Am 04.10.2010 11:09, schrieb Mahender Didwania: Hi, What I am trying is to get something like basex-api.zip available at http://www.inf.uni-konstanz.de/dbis/basex/download/BaseX61-api.zip , only for the newer version (e.g., 6.2.9). Now the file at the URL above packages several other things besides the basex-api (its name BaseX61-api.zip appears to suggest it contains only the basex-api, but that is not the case). My question is: where is the maven pom (if there is one) to create BaseX61-api.zip which includes basex.jar and basex-api.jar besides a few things from examples sub-project as well as several other dependencies? How do you guys create BaseXnn-api.zip? None of the builds of sub-projects basex, api or examples leads to creation of this file and this file is what I need. When I try to create it on my own (searching for the various artefacts and putting them in .zip using a local Maven project), then the resulting server starts fine but every time I perform a REST operation, I get 500 internal server error. I do not want to run basex from within Eclipse. Thanks. ----- Original Message ----- From: "Andreas Weiler" <andreas.weiler(a)uni-konstanz.de> To: "Mahender Didwania" <mahender(a)didwania.co.uk> Cc: basex-talk(a)mailman.uni-konstanz.de Sent: Saturday, October 2, 2010 9:28:52 AM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: [basex-talk] Using the REST interface Hi Mahender, you can check out all three projects (see http://www.inf.uni-konstanz.de/dbis/basex/install ). After that just start the StartJaxRx.java in the examples project. Now you can run the examples from http://www.inf.uni-konstanz.de/dbis/basex/rest . Kind regards, Andreas Am 01.10.2010 17:30, schrieb Mahender Didwania: Hi, I am using Maven to get basex.jar and basex-api.jar and then trying to integrate them with Jetty on the lines of how it is done in the zip file available at http://www.inf.uni-konstanz.de/dbis/basex/download/BaseX61-api.zip - the reason I am doing it in my own Maven build is because 6.1 is not the latest version of basex, but the bundled distribution including Jetty is not available for a later version. I have not tested the bundled distribution (Jetty bundled for access using REST). I am not able to get this to work however - all I get is internal server when I attempt anything other than get application.wadl - e.g., I cannot PUT successfully using the guidelines at http://www.inf.uni-konstanz.de/dbis/basex/rest . I had a cursory look at the java code and could not immediately figure out how Jetty is connecting to the Basex server instance in the StartJaxRx.java or StartJetty.java - to me it merely appears to start the two servers. I will later attempt to use the bundled .zip file available for download, although that is for an earlier version. _______________________________________________ BaseX-Talk mailing list BaseX-Talk(a)mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

2 1

Fwd: basex-api from trunk fails to build
by Mahender Didwania 04 Oct '10

04 Oct '10

Hi, Correction for: For some reason, basex-examples still is dependent upon 6.2.8 and not 6.3 (6.2.8 is available in your maven repo, but the build fails due to other reason mentioned in another post of today from me) basex-examples also refers to 6.3 now (not 6.2.8). However, it has a different issue in that the target folder (used by maven to place results of build into) is a checked in folder as well (it should *not* be part of subversion commits) - this leads to problems unless one deletes this folder before performing svn update. This is just a nuisance I agree, but can easily be rectified. ----- Forwarded Message ----- From: "Mahender Didwania" <mahender(a)didwania.co.uk> To: "Andreas Weiler" <andreas.weiler(a)uni-konstanz.de> Sent: Monday, October 4, 2010 9:17:47 AM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: [basex-talk] basex-api from trunk fails to build Hi Andreas, I *have* checked out all three projects, but cannot build them all in one go (there is no parent pom), so am building them one by one, building basex first, api next and examples last, but api build fails for me due to the reasons mentioned in email below. basex build succeeds, but I then have to manually make the basex.jar available to the api build if I want it to finish successfully. For some reason, basex-examples still is dependent upon 6.2.8 and not 6.3 (6.2.8 is available in your maven repo, but the build fails due to other reason mentioned in another post of today from me) A parent pom should be provided at the top level folder http://www.inf.uni-konstanz.de/dbis/basex/trunk/ ----- Original Message ----- From: "Andreas Weiler" <andreas.weiler(a)uni-konstanz.de> To: "Mahender Didwania" <mahender(a)didwania.co.uk> Cc: "basex-talk" <basex-talk(a)mailman.uni-konstanz.de> Sent: Monday, October 4, 2010 9:04:08 AM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: [basex-talk] basex-api from trunk fails to build Hi, just check out all three projects: http://www.inf.uni-konstanz.de/dbis/basex/install and build it. Andreas Am 04.10.2010 10:01, schrieb Mahender Didwania: > Hi, > > The basex-api has dependencies for basex.jar version 6.3 and basex-api.jar version 6.3, but these are not available. So the project fails to build. > > What is the workaround? > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk(a)mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

2 1