The main reason concerns a revisiting of one of the module's main intended uses, which was to support the idea of any database-related activity being representable by a SQL routine or imitation thereof. An implementation of a SQL routine that my module describes/models/defines could either be stored in a database schema (eg: as a SQL stored procedure, function, or trigger), or it could be stored on the client/application side (eg: as a fusion of Perl code and DBI calls). But from the application's point of view, the routine simply exists in a locally addressable space and can be invoked more or less like a Perl routine (function or procedure), regardless of whether it is actually in the database or on the client.
A routine is quite generic in scope and can hold complete instructions for any kind of database activity, including arbitrarily complex select queries, DML, schema creation or manipulation, user management, transactions, and connections. Therefore, saying that my module supports or models routines means that it supports and models all types of SQL. It was also designed in the hindsight of SQL-2003, and is not limited to SQL-1992.
This is a bit off the wall, but after giving this considerable thought, what comes to mind is SQL::Mechanize, after WWW::Mechanize.
But while my module can represent SQL effectively, it is not exactly the same as SQL, and can be used with both databases or applications that don't want to talk SQL. Hence, calling it a "SyntaxModel" is somewhat archaic.
Given this, perhaps DBIx::Mechanize would be more appropriate. YMMV.
-- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/
