 |
 |
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 file. 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. Michael -----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 somewhat > 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 do > include <head> elements in the body of the finding aid, we use a value in > @altrender to determine whether the icon that reads "Administrative History" > 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 display > 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 who > 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 repositories. 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 is: "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> contains.