We would like to step back from the current MODS/MADS development and
discuss again the merits of a type library.

We have discussed the possible development of a type library on this list
over the past few years, and it seems that most people contributing to the
discussion think it's a good idea, but not very many people have
participated in the discussion. Now, we've been working for a month or so
on this new approach, and we would like opinions and comments from as many
of you as possible, before committing significantly more time on this.

Specifically, the approach/plan is:

1. Define a type library that includes definitions common to MODS and MADS
(and possibly future schemas in the MODS/MADS family).
2. The first official release of MADS would co-incide with the first
release of the type library and mads would include references to types in
the type library where applicable, in lieu of in-schema definitions.
3. Following the release of the first version of MADS, we would begin
development of MODS version 4, which would also refer to the type library
where appropriate.

A prototype of this plan is available --
1. the draft type library, mstl (metadata schema type library) is at
http://www.loc.gov/standards/mads/mstl.xsd
2. a draft of MADS that references the type library is at
http://www.loc.gov/standards/mads/mads-preliminary-draft-jan-13.xsd
3. A draft of what the current MODS might look like refencing the current
draft type library is at: http://www.loc.gov/standards/mads/mods4.xsd

There are a couple of complexities that a type library presents, and this
is why we're asking for your consideration of this plan before proceeding.

(1) within your mods or mads instances, references to elements defined in
the type library will have to include a namespace prefix. (Only elements
though, not datatypes, and most of the type library will be datatypes, not
elements).

For example:

<mads xmlns:m="mstl">
<authority>
<name> <namePart type="date">july 1</namePart></name>
<authority>
<affiliation>
<m.organization>xxx</m:organization>
<m.email> [email protected] </m.email>
</affiliation>

In this mads record, <organization> and <email> require a prefix, as they
are declared within affiliationType in the type library, however
<affiliation> doesn't require a prefix because it is declared in mads
(with a reference to affiliationType).

(2) There is a concern that fragmentation of schemas will make them more
difficult to read and comprehend. That is, if you're trying to read the
mods schema and there are frequent references to another schema, you'll
have to have both schemas in front of you. (If we do adopt the type
library approach we will employ documentation techniques that minimize
this problem.)

On the other hand the benefits of common libraries are well-understood and
don't need to be re-iterated.

Comments will be appreciated. We thought it would be good to outline some
of the implementation considerations.

Rebecca