> Or, how about extending "external tables" so they can read XML as a table?
> That becomes a more useful import/export utility.

As Jason also suggested...

Since we're talking about plug-ins for other things, how about permitting
custom external format I/O modules.

This is different than Jim's statement that the Y-valve has architecture to
support connecting to different access methods; this is more to have a
subset of tables in a given InterBase GDB file be defined as external
formats.

The current syntax:
CREATE TABLE name EXTERNAL FILE 'filename'...

Could be extended as:
CREATE TABLE name EXTERNAL [ 'format' ] FILE 'filename'...
Where the 'format' corresponds to an identifier of one's plug-in module.

For examples:
CREATE TABLE name EXTERNAL 'XML' FILE 'filename'...
CREATE TABLE name EXTERNAL 'SDF' FILE 'filename'...
CREATE TABLE name EXTERNAL 'DBASE' FILE 'dBase-database'...
CREATE TABLE name EXTERNAL 'GDBM' FILE 'filename'...

The syntax for the fields would not change from the current SQL table
definition. We have to make sure table operations are orthogonal. The
plugin would have the responsibility of implementing a mapping of SQL
columns and datatypes to the underlying external storage. The plugin could
say "not supported" if the table definition includes certain types (such as
Blobs) and therefore the CREATE TABLE would fail.

Bill Karwin