Empty element that carries only attributes is common and allowed in XML. You
could use the language element to supply/specify the langtype and/or lang
attribute (code or name) in Language element, and then use the lang
attribute (code or name) for other elements when needed.
Am I correct on this?
Foster Zhang
===============================================
Systems Department (650) 725-7924
Green Library East, 2nd Fl.(650) 723-3038 (fax)
Stanford University [log in to unmask]
Stanford, CA 94305-6069 library.stanford.edu
-----Original Message-----
From: Metadata Object Description Schema List [mailto:[log in to unmask]]On Behalf
Of Ray Denenberg
Sent: 2002?12?17?(???) 8:02
To: [log in to unmask]
Subject: Re: [MODS] language: comments please
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
