This is indeed a very good idea.

A couple of years ago, I proposed a database abstraction layer called DBO to do this kind of thing. You specify the structure as a schema and then create visitors which walk the schema and perform various operations such as queries, validations, views, etc.

A colleague of mine at the time produced a working demo which you can find in my CPAN directory (id: abw) but it is known to be flaky and more of an experiment than a working product. By all means have a look, but don't expect too much from it :-)

The biggest problem was the lack of a standard way to represent the schema. The recent W3C XML Schema specification addresses this issues and provides a flexible and standards based way to do just this. I've started work on an XML::Schema module which will grok XML schemas and should allow you to build all sorts of cool schema based applications on top of it. Things like automatically generating database abstraction layers, SQL <-> object marshalling code, display/edit forms, validation and so on.

Watch this space, but bear in mind that XML Schema is non trivial, so don't hold your breath waiting for anything too soon.

Sorry I can't be more specific--but it's a very good paper, and worth the search.

Are you talking about this paper? It was one Google search away - see for yourself.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

It sees to me, that 'dirty' meant just the other side of SQL <-> XML mapping. I have similar problem with perl objects persistence in RDBMS.

I need an XML docuent, that is able to describe DB scema. It should describe tables that will be used, their columns, data types, and some aditional information, as a perl regexpt used for validation of input into that table. Kinf of 'consistency' rules.

If there is some XML DTD for such type of information, I rather used this stadard sulution that my proprietary one.

Exactly!

It just seems like a logical abstraction that i find it hard to believe that someone hasn't done it before. either that, or i am missing something.

I mean, it seems facile to come up with a very basic DTD which only specified column names and a series of regexps which that column data must match in order to be accepted.

Of course, this only allows 'intra' data checking; there is still the 'inter'-data checking - looking up external databases to see if X has been entered before etc etc...

either way, being able to specify column data semantics in an external file certainly has it's virtues -- it would be such a simple thing to wrap this in an object:

package SyntaxChecker;

our $Column_Definitions = {};    
BEGIN {
    load_definitions();
}

sub new 
{
    my $proto = shift;
    my $column_name = shift || die;
    my $class = ref $proto || $proto;

    my $this = {
        column_name => $column_name,
        column_definition => $class->_get_definition(  
                             $column_name ),
        regexp => [ $class->_get_regexps( $column_name) ],
        regexp_cache => [],
    }; 

    return $this;
}

sub get_cached_regexps
{
    my $this = shift;
    return @{ $this->{'regexp_cache'} };
}

sub validate
{
    my $this = shift;
    my $input_data = shift || die;
    my $matched;

    if ( my @regexps = $this->_get_cached_regexps() ) {
        foreach my $regexp_sub ( @regexps ) {
            $regexp_sub->( $input_data ) ||
                die $this->{'column_definition'};
            $matched++; 
        }
    } else {
        foreach my $regexp ( @{$this->{'regexp'}} ) {
            my $code = eval "sub{ $input_data =~ $regexp }";
            push @{ $this->{'regexp_cache'} }, $code;
        }
        return $this->validate( $input_data );
    }
    
    return $matched;
}
[download]

ok, so it's not a complete module -- no error checks or accessors or xml loading/parsing, but that took me all of 20 minutes, so a complete version wouldn't be much extra...

just need a good DTD for the xml description... any takers???

d_i_r_t_y