Date:         Tue, 17 Dec 2002 09:54:07 -0800
Reply-To:     Metadata Object Description Schema List <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         Rick Beaubien <[log in to unmask]>
Subject:      Re: language: comments please
Comments: To: Metadata Object Description Schema List <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>
Content-Type: text/plain; charset="us-ascii"; format=flowed

The proposal to express language consistently through attributes makes very
good sense to me.

I am personally not bothered by "linked" attributes.  But this is partly
because my involvement with MOA2 and METS has accustomed me to these. In
METS, for example, there is a "METADATA" attribute group that consists of a
required "MDTYPE" attribute and an optional "OTHERMDTYPE" attribute.  The
MDTYPE value must be drawn from an enumerated list.  But if the value of
the MDTYPE attribute is "other", then it can be qualified with its
associated and unrestricted OTHERMDTYPE attribute.

Rick

At 11:02 AM 12/17/02 -0500, you wrote:
>Rick Beaubien wrote:
>
> > Given that the MODS language element supports both ISO 639-2 and RFC3066, I
> > 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 that
> > included both a LANG and LANGTYPE attributes along the lines of the
> > following:
> >
> > <xsd:attributeGroup name="LANGUAGE">
> >                  <xsd:attribute name="LANG" type="xsd:string"
> use="optional"/>
> >                  <xsd:attribute name="LANGTYPE" use="optional">
> >                          <xsd:simpleType>
> >                                  <xsd:restriction base="xsd:string">
> >                                          <xsd:enumeration value="RFC3066"/>
> >                                          <xsd:enumeration
> value="ISO639-2b"/>
> >                                  </xsd:restriction>
> >                          </xsd:simpleType>
> >                  </xsd:attribute>
> >          </xsd:attributeGroup>
> >
> > Such handling would, I think, be most consistent with the current language
> > element.
>
>Rick -- Thanks for the suggestion.  We've had quite a bit of discussion
>here and
>we agree with this approach.  But we have a couple concerns (and would like to
>know if other people see these as problems).
>
>First, to really be consistent we would need to represent language
>consistently as
>an attribute as opposed to an element (in fact we'd have to do that to use the
>above approach).  An attribute on an element is the appropriate way to
>represent
>the language of the element. However, language is itself currently an
>element (not
>an attribute), as it represents the language of the item. So we propose to
>represent the language element as an element where the element content is not
>signficant (may be empty), where language and language type are both
>represented
>as attributes.  That way it can use the attribute group as
>suggested.  This may
>seem a bit of a cludge but I think the benefits of this approach (the
>consistency
>that's gained) outweigh the slight clumsiness.
>
>Secondly, this approach represents language type as an attribute qualifying
>language, itself an attribute. (It seems like a cludge to allow an
>attribute on an
>attribute.) If  nobody else is bothered by this then I suppose we aren't.
>
>--Ray


----------------------------------------------------------------------------
Rick Beaubien
Lead Software Engineer, Research and Development
Library Systems Office
Room 386 Doe Library
University of California, Berkeley 94720-6000
510-643-9776