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. Andy.