To reiterate, I did say that I thought adding a type attribute had merit.
Our use a the Minnesota Historical Society of the altrender attribute is
certainly a stretch, though arguably less a stretch in our case as it
controls how an icon, or rather which icon, is rendered rather than
supplying text. But a minor hack nevertheless.
As to the use of encodinganalog, having a stylesheet discern between "545 1"
and "545 0" puts an awful premium on string pattern matching, especially
since there is no standard (except in the RLG guidelines) as to how the
values are represented in the attribute. Is "$545 0" or "545 0"? Lots of
opportunities for typographical errors.
To say that <head> elements are not required is true but not particularly
useful. Almost nothing is required by the DTD. EAD is not a data content
standard and is not in the business of prescribing or enforcing the content
or even presence of particular elements. With two or three exceptions, the
required elements all have to do with the identification of the electronic
Even if one had a type attribute, it would be outside the domain of EAD to
define the relevant values if for no other reason than that the terms might
be different in different countries. The need to make EAD even more
internationally useful in this way was one of the reasons behind removing
many of the prescribed lists of values for attributes in version 1.0. Even
more so because, as is pointed out, ISAD(G) does not make a distinction.
From: M. Carlson [mailto:[log in to unmask]]
Sent: Wednesday, October 01, 2003 10:25 AM
To: [log in to unmask]
Subject: Re: Question about <bioghist>
On Tue, 30 Sep 2003, Fox, Michael wrote:
> The Minnesota Historical Society uses the altrender attribute in a
> similar way. The text of our "table of contents" consists of a series of
> icons rather than the text taken directly from <head> elements. While we
> include <head> elements in the body of the finding aid, we use a value in
> @altrender to determine whether the icon that reads "Administrative
> or the one that says "Biography" appears.
> That said, Marsha's suggestion for a type attribute has merit.
> On the other hand, I am not sure that personally agree that all this
> information should always be left to the stylesheet. I think that it is
> probably useful to include heads and labels, if only as a default when
> finding aids leave the creating institution or consortium and go off to
> knows where to be interpreted by a stylesheet that may assume their
But since <head> elements are not *required* elements, that seems to imply
that a style sheet should at least provide a "default" on its own without
"assuming" anything and that "tests" should be performed on whether a
particular combination of parent/child elements exist, not on whether a
<head> element exists among those parent/child elements.
The benefit of having a "type" attribute would be that some consistency in
encoding it could be suggested among repositories who want to distinguish
between different types of <bioghist> notes. This is best handled by an
attribute (consistently applied among repositories) rather than a value in
a <head> element which will vary (or perhaps omitted) among those
I don't think any such consistency could be imposed on an attribute such
as 'altrender'. According to the tag library, the attribute's definition
"The content of the element should be displayed or printed differently
than the rendering established in a style sheet for other occurrences of
In this case, it's not so much to print a different heading (although that
may be a result) but to indicate the type of data that <bioghist>