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.