Here's an example of a submission of data:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE cipresml SYSTEM "cipres.dtd">
<cipresml version="0.0.1" sessionID="1" status="0" user="rvosa" servic
+e="Repository">
    <submission>
        <taxa tBID="Taxablock">
            <taxon tID="taxonID">
                <name>taxon name</name>
            </taxon>
        </taxa>
    </submission>
</cipresml>
[download]

In this case there are three tables involved: the sessions table (which stores the sessionID, the username and a timestamp), the taxa table (which stores the tBID, and the sessionID as a foreign key) and the taxon table (which stores the tID, the name, the tBID and the sessionID - the last two are foreign keys referencing the taxa table).

Here's an example of a query, in SQL, that I want to result in a structure like that descending from the <submission> element:

SELECT name FROM taxon WHERE tBID='Taxablock' AND sessionID=1 AND tID=
+'taxonID';
[download]

Is that the only style of submission you'll get? You implied that your interpreter was going to have to intuit what the submission means. This may be a stupid question but can't you get a meaningful specification for the schemas you'll be expected to consume? From there you just note which schema style was retrieved and use an output reformatter that writes to that style. Also, have you looked at XQuery? I've heard of it in similar contexts except that it may be already designed to handle the problems you're just going to have to invent around.

I think the w3c has a spec for sql and xml called xsql.
There is also some perl related development going on with this
see the following link...
perl xsql info

I think the w3c has a spec for sql and xml called xsql.

Thanks for the heads up, looking into this now...

Just wondering, why is <resultset><row/></resultset> no good? It seems to me that if all the client is expecting is simple tabular data (say, to be displayed to the end user as a simple table) then that ought to be good enough. Or at least, that's what I thought when I did something very similar at work recently (sadly not in Perl).

I guess the thing is that if your client expects back highly structured data with specific meanings it's a different matter. I'm not too familiar with modules for this, but it seems like one good way might be to just store your XML templates somewhere (if they'll be fairly static), and use some kind of table to map the results from your query to individual locations (defined using XPath perhaps) in your XML template. I believe you could use XSLT for that too though I haven't tried.

I guess the thing is that if your client expects back highly structured data with specific meanings it's a different matter.

That's exactly the problem. Here's the dilemma: I could restrict the types of queries you can do to a subset where the results are neatly marked up (using a template) to get the data in a form that's more complex than <resultset><row/></resultset> but then I'm constrained in terms of the things you can ask, or I can allow for more flexibility in terms of the queries but then I can't really see how I could get output that is not as generic.

But from the sound of what you've said, what you need is a templating system more than an XML querying system. Here's an example that produces output in the same format as your submission from multiple rows returned from a database query. The script is fully functional except for the missing DBI connection params.

#!perl -w
use strict;
use DBI;
use HTML::Template;
my $query   = <<'';
SELECT tID,tBID,name
  FROM taxon
 WHERE sessionID=1 AND name<>'baz'

my $template = <<'';
<submission><tmpl_loop results>
    <taxa tBID="<tmpl_var tBID>">
        <taxon tID="<tmpl_var tID>">
            <name><tmpl_var name></name>
        </taxon>
    </taxa></tmpl_loop>
</submission>

my $dbh     = DBI->connect( ... );
my $results = $dbh->selectall_arrayref($query,{Slice=>{}});
my $tmpl = HTML::Template->new
    ( scalarref         => \$template
    , die_on_bad_params => 0
    );
$tmpl->param( results => $results );
print $tmpl->output;
__END__
[download]

Hey, thanks for that. Yup, I think it'll have to be something like this, though this limits me to only certain types of queries.