I like the changes!  Below are a few comments/questions...

On Friday, August 22, 2003, at 03:54  PM, Rebecca S. Guenther wrote:

> 2. Declares all first-level MODS elements (those immediately
> subordinate
> to <MODS>) as global, so they can be root elements of instance
> documents,
> or imported into other schemas..

Nice.

> 5. Adds the following enumerated values under <typeOfResource>
>         sound recording-musical (MARC Ldr/06 value "j")
>         sound recording-nonmusical (MARC Ldr/06 value "i")
> ("Sound recording" by itself will be retained to be used when a
> mixture of
> musical and nonmusical or if the user does not need to make the
> distinction.)

I don't really understand the need for this, but oh well.

> 7. Adds under originInfo:
>         dateValid (MARC 046$m and $n)

I've earlier raised this privately as I've tried to code some example
records:

Would this element be appropriate for an "access date" for online
material?  I think there needs to be some way of coding this
information, at least for citations.

>         dateModified (MARC 046$j)
>         copyrightDate
>
> For all dates adds attribute "qualifier" with values: approximate,
> inferred, questionable

Great; thanks!  But not for names?

> 8. In <place>, <role>, and  <language> changes to a consistent
> treatment
> of code or text as follows:
>         <place> (MARC 008/15-17; 044, 260$a)
>                 <placeTerm>

So this allows further parsing of places?  So I could have the
following?

<placeTerm type="city">New York</placeTerm>

>         </place>
>         <role> (MARC 1XX, 7XX $e and $4)
>                 <roleTerm>

Why the need for this element?  Is it to allow multiple role terms?

>                 Attributes: authority, type (code or text)

I've not mentioned this before, but I find the text and code elements
in v2 awkward, so this is a nice improvement.

> 12. Adds <part> to relatedItem (with type="host")  to enable detailed
> coding for generating citations:
> <part>
>         <detail>
>         Attributes: type, order
>         Type: Suggested values include part, volume, issue, chapter,
> section, paragraph, track
>    Order: contains a number
>         Subelements:
>                 <number>
>                 <caption>
>                 <title>

Related to the comment above about the code and text elements that are
being converted to attributes, cannot this information (certainly the
number) be handled via an attribute switch?  Or is the idea here that
one can then mix text and numbers with the detail element?

>         <extent>
>         Attribute: unit

Why use a different attribute name here for the same thing in <detail>?

Bruce