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

custom resolver / XML catalogs
by Imsieke, Gerrit, le-tex 27 Jul '10

27 Jul '10

Dear Team, We need to deal with XML that contains a DOCTYPE declaration and named entities. Unfortunately the DTD sometimes isn't available at the system location (e.g., "E:\mydoc.dtd") given in each document's declaration. Is it possible to specify a custom resolver such as org.apache.xml.resolver.tools.CatalogResolver so that the DTD can be found by virtue of a catalog, and consequently the entities can be resolved? If catalogs are not available, we'll have to resolve the entities (and remove the DOCTYPE declaration) in a preprocessing step using xmllint or saxon. This is acceptable, we just need to know how to proceed. Many thanks, Gerrit

2 1

Clinical Trial Magnifier - now 21, 305 subscribers from 157 countries
by Clinical Trial Magnifier 27 Jul '10

27 Jul '10

Dear Colleague, You are invited to subscribe to a new free electronic monthly newsletter, the Clinical Trial Magnifier ( http://t.rs-tk.com/t.aspx/subid/24146128/camid/46345/www.clinicalresearchcl… ). The Magnifier is a free electronic newsletter that was launched in January 2008 by Johan Karlberg, MD, PhD, the Director of the Clinical Trials Centre at the University of Hong Kong. The Magnifier has today 21,305 subscribers representing 157 countries. The next Clinical Trial Conference ( http://t.rs-tk.com/t.aspx/subid/24146128/camid/46345/www.ctmconference.com/… ) will be November 24-26, 2010 in Kota Kingabalu, Sabah (the Land Below the Wind), Malaysia; the main conference theme will be Investigator Incentives for Participation in Industry Sponsored Clinical Trials. There are already 116 registrations by clinical trial professionals from 42 countries and about half have signed up for the pre-conference courses. Details are provided in the June 2010 Magnifier issue. The June 2010 Magnifier Issue has the following contents: Editorial. New Book on Clinical Trials - Reviewing Clinical Trials: A Guide for the Ethics Committee. A case study: Refining Clinical Research Infrastructure. Magnifier Subscriber Survey The Ethics Guide. Interview with 15 Magnifier Subscribers. The Study Site SOP Standardization - 4S - Project. Magnifier Advisory Board Members. The most recent May and June 2010 Industry-sponsored Clinical Trials Registered. Highlights Next Issue - Clinical Trials Overseen by the US FDA. Challenges to FDAs Ability to Monitor and Inspect Foreign Clinical Trials. Clinical Trial Conferences: November 2010, Kota Kinabalu, Malaysia Yours Sincerely Johan PE Karlberg, MD, PhD Clinical Trials Centre The University of Hong Kong P.S. If you have any kind of queries or messages please contact me directly using: EditorialBoard(a)ClinicalTrialMagnifier.com ( ) Delete my email from the Magnifier database. ( http://s.rs-tk.com/Unsubscribe.aspx?sub=24146128&user=4658&campid=46345&typ… )

1 0

Feature Requests: Results
by Christian Grün 26 Jul '10

26 Jul '10

Dear all, some time ago I invited you to mail us your personal wish list for new, or revised, BaseX features. This mail serves as a little summary on the requests we've got so far, along with a short status report: QUERYING: - Support for XQuery 1.1 (most of all: group by): currently implemented, many features have already been finalized - More libraries: additional modules for file operations, http requests, etc. (based on EXPath, etc.): in progress - XSLT Transformations: Andy C. kindly offered some support! DATABASE: - Collections functions: commands for adding/deleting documents have been revised in the latest version; feedback is welcome! - Backups: currently implemented - Database triggers: design in progress - Schema validation: won't be included that soon, as BaseX works (and will stay) schema oblivious - Retaining CData: not intended by the specs; instead, serialization parameters should be used… TRANSACTIONS: - Rollbacks: future work, but will definitely be implemented - Multiple writers: will be supported at least on database or document level - Index Updates: design in progress INTERFACES: - Communication with relational databases: existing standards/solutions might be investigated first to stay conformant, and support as many databases as possible (suggestions?) - XQJ: Improved binding of Java types (might require XML schema support to be properly implemented) GUI: - XQuery Editor: syntax-based highlighting, code completion: design in progress GENERAL: - Commmercial support: on the way - Full Documentation: always in progress, but edged out by other todos… - Installer for Windows version: currently implemented - Service/Daemon: already implemented (BaseX server can be run as service via -s); installer might include Windows Service Thanks again for your contributions; please remember us if I've forgotten something. We'll keep you informed – and you can be sure that we'll always keep BaseX as light-weight as possible. Christian ___________________________ Christian Grün University of Konstanz Department of Computer & Information Science D-78457 Konstanz, Germany Tel: +49-7531-88-4449, Fax: +49-7531-88-3577 http://www.inf.uni-konstanz.de/~gruen

1 0

support for line/column numbers when errors occur
by Godmar Back 26 Jul '10

26 Jul '10

When debugging complex XQuery expressions, we frequently encounter errors such as these [XPTY0004] Invalid cast from empty-sequence to string: () when an XPath expression evaluates to an empty sequence. When using BaseX's XQJ implementation, the line and column number fields of the corresponding XQQueryException are both 0. This lack of pinpointed information makes debugging the Xquery expression time consuming. It would be tremendously helpful if the exception contained more information about the source of the empty sequence that's causing the XPTY0004 error. Also, if I weren't to use BaseX's XQJ implementation, would I be receiving more helpful error messages? - Godmar

1 0

BaseX adds bogus duplicate default namespace prefixes when inserting nodes
by Godmar Back 26 Jul '10

26 Jul '10

To follow up on my previous email, we observe the following. We run a query: declare namespace libx='http://libx.org/xml/libx2'; declare namespace atom='http://www.w3.org/2005/Atom'; declare variable $entry as xs:anyAtomicType external; declare variable $id as xs:string external; declare variable $feed as xs:anyAtomicType := doc('libx2_feed')/atom:feed; delete node $feed/atom:entry[atom:id=$id], (: INVESTIGATE: this results in wrong xmlns entries :) *insert node $entry into $feed* whereby we bind 'entry' to a DOM node using the org.w3c. Implementation. When we print the about-to-be-inserted entry from Java code prior to insertion, we see: <?xml version="1.0" encoding="UTF-8"?><entry xmlns=" http://www.w3.org/2005/Atom" xmlns:libx="http://libx.org/xml/libx2"> <id>3</id> (rest omitted) If we run a database dump via the org.basex.BaseX program (query: doc('libx2_feed')) right after the update, we see this: <entry xmlns="" xmlns="http://www.w3.org/2005/Atom" xmlns:libx=" http://libx.org/xml/libx2"> <id>3</id> <title> (rest omitted) Other than the spurious 'xmlns=""', the rest looks ok. It seems to me that BaseX should never allow two default namespace prefixes for any element. - Godmar

3 17

Bea Sancho te ha invitado a Tuenti
by tuenti.com 26 Jul '10

26 Jul '10

1 0

BASEX and PHP: for $node in doc("factbook") -- ERROR: Unknow
by johanna.vompras＠uni-bielefeld.de 26 Jul '10

26 Jul '10

Hi all! I have written some PHP Scrips with test queries to the factbook database, which are are well executed at my local machine (Windows, XAMPP, BaseX on localhost, Port 1984). Now, I have ported my examples to a remote server, and it seams that the query string is not accepted. For example: The query (for $node in doc("allbus")//(d:QuestionItem|d:MultipleQuestionItem) return data($node/@id)') results in the following error: Unknown command 'for'; try "help". Other queries result in Error: 0 instead of 1 commands received. We have BaseX Client running and the queries can be submitted through the linux console (> xquery for $node in doc("factbook")//country return $node). Opening the database and querying also works. But from my PHP scripts it does not work. Does anybody know went wrong with my installation? Here is the example: <?php include('BaseXClient.php'); //set content-type header header('Content-type: application/json'); // commands to be performed $namespaces = 'declare namespace d="ddi:datacollection:3_0";'; $cmd = 'for $node in doc("allbus")//(d:QuestionItem|d:MultipleQuestionItem) return data($node/@id)'; $cmd2 = 'for $node in doc("allbus") //(d:QuestionItem|d:MultipleQuestionItem)/d:QuestionText/d:LiteralText/d:Text return data($node)'; try { // create session $session = new Session("129.......", 9000, "admin", "admin"); //create JSON data structure $startJsonObject = "{ questions: ["; $endJsonObject = "]}"; try { $query = $session->query($namespaces.$cmd); $query2 = $session->query($namespaces.$cmd2); $counter = 0; while($query->more()) { $next = $query->next(); $query2->more(); $next2 = $query2->next(); $counter++; ................ etc... ?>

1 0

BaseX XML interface
by NewIntellectual 24 Jul '10

24 Jul '10

Godmar Back asks: I'm still curious what XML interface I'm missing. While I agree that published interfaces should work properly, I think a simple point is being completely missed. Both XML and XQuery are, by their nature, human readable text, regardless of their complexity. That means that queries can be sent simply as text strings, and results of any size can also be returned in that way and then parsed as XML fragments in any number of myriad ways, including parsing to an in-memory DOM. I successfully use this approach to query an XML database representing close to 200,000 pages of text and to retrieve pretty large XML fragments (actually documents with a single root element) quickly. This may be a simple approach but there is no loss of generality by using it - in other words, using a more complex interface will not let you do some XQuery processing that cannot be done with this approach. You can use the following code to access BaseX for example (in this case to a local server using default permissions). I am prefixing text to make the result string an XML document but your code may not need it: package [...]; import java.io.*; import java.util.*; import org.basex.server.ClientSession; public class QueryText { public String doQuery(String xquery) { ClientSession session; String result; ByteArrayOutputStream buffer = new ByteArrayOutputStream(); session=null; result="NO RESULT"; try { session = new ClientSession("localhost", 1984, "admin", "admin"); session.execute(xquery, buffer); result="<?xml version='1.0' encoding='UTF-8'?>"+buffer.toString("UTF-8"); } catch(Exception e) { ... } finally { try { session.close(); } catch(Exception e) { ... } } } }

4 7

Addendum to last post
by NewIntellectual 24 Jul '10

24 Jul '10

The code I posted accidentally omitted a critical step - add a 'return result;' as the last statement in the doQuery method.

1 0

working with XML databases (BaseX) in Java
by Godmar Back 23 Jul '10

23 Jul '10

Hi, I'd like to follow up for the benefit of the list on this comment by Christian: > As mentioned, our DOM interfaces haven't been tested very much, but > your focus on DOM and XQJ might inspire other users to play around > with this interface as well, and give us more feedback. Could people share their approaches to working with XML in Java? My (apparently outdated) knowledge is that only two approaches are in wide use: those that use an in-memory representation of an XML document (or fragment) - e.g., either XOM, org.w3c.'s DOM, JDOM, etc. or approaches that use a stream-based approach (SAX). Naively, I would have expected that XML databases such as BaseX would provide excellent support for at least one of the widely used DOM interfaces. (In fact, Christian made an earlier comment that BaseX uses an "optimized" (albeit incomplete) implementation of org.w3c.'s DOM classes.) Are there other existing approaches besides DOM that would allow me to retrieve and update XML documents, and represent portions of them in memory? - Godmar

1 0