I'm in agreement that record sets are a good thing to have.  I would prefer
two DTDs -- one for a single record and a second one for a set of records.
This is done easily enough with a single entity file that defines MODS and
two DTDs that load that entity file to define a single record or a set of
records. There is no reason everyone should have to define a local DTD to
handle record sets.

Geoff Mottram

----- Original Message -----
From: "Houghton,Andrew" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, April 03, 2002 4:00 PM
Subject: Re: [MODS] Recordsets

> From: Jerome McDonough [mailto:[log in to unmask]]
> Sent: Wednesday, April 03, 2002 10:28 AM
> I'm joining this discussion a bit late, but I'd actually like to argue
> *against*
> a recordset notion within MODS.  This strikes me as a holdover from
> DTD-thinking.  If you need to keep multiple MODS records in a single
> file and validate the whole thing, just write your own, local
> schema for
> that purpose that incorporates the MODS schema for the individual
> record definition.
> One of the big advantages of XML Schema is the ability to treat
> bits of XML in a much more modular, mix-and-match fashion than
> was possible using DTDs.  I'd say MODS should stick to defining

This is a "big" myth propagated by the XML Schema community.  DTD's
can very easily be as modular and used in a mix-and-match fashion,
just like XML Schemas.  XML Schemas provide only "minor" advantages
over DTD's and for those "minor" advantages, if you rethink your
content model you don't really need them.

> a single record format.  If you need to have a file containing
> multiple MODS records, it's easy enough to enable that using MODS
> as part of a more encompassing schema.

Either you can define one DTD/Schema that incorporates the concept
of record sets or you can define one DTD/Schema for a single records
and one for a set of records.  Regardless, it would be better to
have it defined one way, via a standard, rather than an infinite
number of ways that each metadata community might implement it.  An
interoperable way is always preferable.

So I respectfully disagree.