Many thanks, everyone, for these replies. It's very helpful to have these perspectives. Maybe if ISAD (G) doesn't distinguish one type of note from the other, we shouldn't either.
Manuscripts & Special Collections
University of Washington Libraries
P.O. Box 352900
Seattle, WA 98195
[log in to unmask]
On Wed, 1 Oct 2003, Fox, Michael wrote:
> 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.
> -----Original Message-----
> 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
> > presence.
> > Michael
> 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
> the element"
> 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>