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