Yes, this is a purely XML approach, but it is also a huge stretch of
what the <emph> element is by definition to be used for and results in
the same need to transform the nodes into an acceptable view in output
aimed at the public (at least in our case). I have found that XSLT can
handle either of these approaches equally well.
In our usage of <emph>, we have expanded the scope of the tag to include
other types of formatting possibilities by mapping the ALTRENDER
attribute to the STYLE attribute in HTML and incorporating Cascading
Style Sheet styles in this attribute; something that the <emph> element
is more suited for.
But in the final analysis, we are all aware that there is really no
elegant solution at this point for adding granularity where the
structure of the DTD doesn't offer it. When we switch over to a schema
model for EAD, we will be in a much better position to address this
problem. In the meantime, the best rule to follow is to be consistent
in your approach and use of XML elements and attributes or structured
data so that at the point when you can map your data to a better system,
you'll be in a good position to do so.
John Harrison wrote:
> On Wed, 2006-05-03 at 15:32 -0700, Mark Carlson wrote:
>> We addressed the granularity problem in <controlaccess> terms by
>> embedding the actual subfield codes within the EAD elements:
>> <subject source="lcsh" rules="aacr2" encodinganalog="650">School
>> integration$zWashington (State)$zSeattle</subject>
> But this leaves MARC specific code in the actual text of the finding
> aid. This is not a good approach from an interoperability point of view.
> An approach recommended for use in the Archives Hub (UK
> http://www.archiveshub.ac.uk/) is to wrap the marc subfield analogs in
> emph tags and apply an altrender attribute to specify which marc
> subfield they apply to. e.g.
> <subject source="lcsh" rules="aacr2" encodinganalog="650">School
> integration <emph altrender="z">Washington (State)</emph> <emph
> If you do this, you don't need to worry about stripping the subfield
> codes in non-MARC oriented output.
> Relating back to the original question, maybe altrender attributes could
> be used to tag subfields of the MARC 530 field.
Computer Support Analyst
Special Collections Division
University of Washington Libraries
Seattle, WA, 98195