After skimming through Bruce Toback's reply (good info, thanks) I now
have a revised analogy (beyond copylib/fixed record).

Sounds like Self Describing (SD) files (I believe that Robelle
makes/made use of these. An age old paper comes to mind. Anyone at
Robelle care to comment?) I think Query uses them too (I never got into
the details).

Or, how about, Quiz workfiles with the little schema embedded.

Or, for data transfer, create an Image database with a single
stand-alone
Detail dataset and the receiver can make DBINFO calls to their heart's
content. (Yeah, I know, not an open-system approach).

I do see uses for XML for data formats that change often, but having a
fixed record layout (that very rarely changes) compiled into the
programs
seems easier for the programmer to understand, code, debug and faster to
execute (the old flexibility vs. speed trade-off). The cpu cycles aren't
free and I doubt that many shops have much excess time in the morning
after the night's batch run.

I might have this all wrong but, are the XML tags embedded in each
record? That is, does each record have to have it's tags parsed? If so,
this seems rather redundant unless your appl calls for various record
formats all intermixed (but I would still vote for a rec-type field
instead for most appls).

If all the records are the same, then parsing the tags just once at the
start of the run and then cutting up the record wouldn't be quite so
expensive.

Erik (still not quite ready to run out and buy my first XML book)
Vistica
(a.k.a. eVistica :-)