 |
 |
On Aug 10, 2010, at 11:59 AM, Ethan Gruber wrote: > Sounds like a good plan, but I wanted to throw in my two cents on your > workflow. <unitid> is intended to be an optional element and describe an > actual unique identifier that the object or collection has been given by the > hosting institution. For example, accession number. <unitid> isn't > absolutely intended to be a machine-readable value (for example, xml:id), > though it could be. I think what you want to do is populate the id > attribute for each component with a unique xml:id. This way you can make > all your components have a machine-readable identifier while preserving any > actual unique identifiers that describe the component. Ethan, thank you for the feedback. Yes, I have come to learn that unitid is not necessarily intended to be machine-readable, but I intended to make it such in my locally cached versions of the EAD. This is because of Archon. For better or for worse, it is possible to create URL from the unitid that will point directly to an Archon and the sub-section of the EAD file. Ultimately this solves the problem of formatting the EAD for display as well as navigating it. An xml:id would not do the same trick because Archon would not know how to handle it. -- Eric Morgan