No it's not exactly the case that the lang attribute is redundant. What
RFC 3066 says is that if the language has an ISO 639-1 code (i.e.
2-character code), use it. If it doesn't, use another code from the larger
set of ISO 639-2. So what that means is that using xml:lang, German is
coded as "de" and Aramaic (which has no 2-character code) is coded as
"arc". But in MARC and ISO 639-2B, German is coded as "ger" and Aramaic is
(still) "arc".

As I said, MODS needs to support the codes used for 30+ years in the
bibliographic world. There's no reason why it can't handle both. Here is
one of several messages that I mentioned was sent out to the list in
Dec. 2002 on this issue. We had a full discussion of this issue at that
time (see below).


On Tue, 18 Jan 2005, Andrew E Switala wrote:

> That's what I originally thought, i.e. ISO 639-2 codes more languages
> than RFC 3066. But the part of RFC 3066 I quoted indicates that it
> supports ISO 639-2 (second bullet point below). So the even for purposes
> of MARC compatibility, the lang attribute is redundant and all
> occurences of it can be replaced by xml:lang.
> --Andy

Message from Dec. 2002:

Date:         Wed, 11 Dec 2002 11:48:46 -0800
From:         Rick Beaubien
Subject:      Re: FW: [MODS] language: comments please (fwd)

You're right, Mark--I can see that I need to elaborate my views a little.

I think that MODS definitely needs to support ISO639-2b because the 3
character codes it represents have been used in libraries for so long.
This support is essential. In the interests of flexibility, I think a
strong argument can be made for supporting RFC3066 in a manner such as is
already provided for in the MODS language element.  MODS already has
enough flexibility that I don't think that "interoperability" can simply
be assumed anyway.  Whatever decision is finally made, however, I think
that the provisions of the language element and the provisions of any
language attribute should be consistent and well-aligned.


At 12:39 PM 12/11/2002 -0600, Mark Needleman wrote:
>this certainly solves the problem from an xml point of view in an elegant
>way - but Im not sure it deals with Rebecca's underlying issue (which if
>interpeting it correctly) is asking whether or not MODS should allow both
>and 3 letter codes or somehow try to mandate something more restrictive
>thus more interoperable) - if it is decided that both the 2 and 3 letter
>codes need to be there it would be nice to be able to have the
>clearly defined in the xml
>Mark H Needleman
>Sirsi Corporation
>Product Manager - Standards
>1276 North Warson Road
>P.O. Box 8495
>St Louis, MO 63132-1806
>Phone: 800 325-0888 (US/Canada)
>        314 432-1100 x318
>Fax: 314 993-8927
>Email: [log in to unmask]
>---------- Forwarded message ----------
>Date: Wed, 11 Dec 2002 09:34:40 -0800
>From: Rick Beaubien <[log in to unmask]>
>Reply-To: Metadata Object Description Schema List <[log in to unmask]>
>To: [log in to unmask]
>Subject: Re: [MODS] language: comments please
>Given that the MODS language element supports both ISO 639-2 and RFC3066,
>feel that any provision for language attributes should as well, just for
>the sake of consistency.  However, to make the authority explicit and to
>avoid having two parallel language attributes to contain the language
>value, you might want to consider defining a language attribute group
>included both a LANG and LANGTYPE attributes along the lines of the
><xsd:attributeGroup name="LANGUAGE">
>                  <xsd:attribute name="LANG" type="xsd:string"
>                  <xsd:attribute name="LANGTYPE" use="optional">
>                          <xsd:simpleType>
>                                  <xsd:restriction base="xsd:string">
>                                          <xsd:enumeration
>                                          <xsd:enumeration
>                                  </xsd:restriction>
>                          </xsd:simpleType>
>                  </xsd:attribute>
>          </xsd:attributeGroup>
>Such handling would, I think, be most consistent with the current
>Rick Beaubien

Rick Beaubien

Lead Software Engineer: Research and Development
Library Systems Office
Rm 386 Doe Library
University of California
Berkeley, CA 94720-6000