Amy, You are correct on the content model. My recollection, perhaps faulty, is that NMTOKEN was chosen for technical reasons to support locally defined entities that could, in this case for example, prescribe a locally defined set of possible values for a given attribute even when the EAD DTD is more permissive. For example, in Sweden the national archives could create a list of possible valid values for the type attribute and the French could do the same. Both would limit national practice while still being valid EAD since they would be, in effect, subsets of the range of possible values for TYPE. The way to do this is described in the file eadlocal.ent. My sense is that this a fairly complex technical matter and my advice is that if one does not know enough SGML/XML to understand what's happening in this file that it's best to stay away from it. The following description from the file eadlocal.ent may clarify the difference between CDATA and NMTOKEN. "Attribute declarations (as literal entity values in the following parameter entities) have three components: name, type, and default. In the following example, "rules" is the name of the attribute, "NMTOKEN" is the attribute type, and "#IMPLIED" is the attribute default. 'rules NMTOKEN #IMPLIED' The following two attribute types are used: NMTOKEN: an XML key word meaning that the value of the attribute must be a NAME TOKEN. CDATA: an XML key word meaning that value of the attribute may be virtually any Unicode character, including a whitespace. Both NMTOKEN and CDATA may be replaced by one or more values (an enumerated list) that conform to the XML rules specifying the composition of a NMTOKEN. A NMTOKEN may include any combination of the following: Letter, digit, '.', '-', '_', or ':'. NOTE: A NMTOKEN MAY NOT contain a space. Thus while CDATA allows virtually any combination of characters (including whitespaces), constraining the values in the DTD will necessarily requiring conforming to the XML rules for NMTOKEN." The bottom line, however, is that you can include any value in TYPE that contains letters, digits, periods, hyphens, underscores, or colons. Michael -----Original Message----- From: Amy McCrory [mailto:[log in to unmask]] Sent: Wednesday, September 03, 2003 8:55 AM To: [log in to unmask] Subject: Re: alternate container markup in EAD 2002 Thanks to both Michael and Kris for the replies. My next question: where can I look at the content model? The 2002 Tag Library still says "NMTOKEN" for the type attribute in <container>. My ability to interpret the information in the DTD itself is limited, to put it mildly, though improving. Amy At 08:02 AM 9/3/2003 -0500, you wrote: >Amy, > If you look at the new content model in EAD 2002 for the type attribute >in <container>, you will see that the restricted list of possible values, >e.g., box, folder, reel, othertype, etc. is no longer there. The type >attribute can now contain any form of character data (CDATA). As a result >there is no longer a need for the othertype attribute as any value may be >found directly in type. This change was made because the former semi-closed >list was felt to be too restrictive and U.S. or at least English-centric. > >Michael > >-----Original Message----- >From: Amy McCrory [mailto:[log in to unmask]] >Sent: Wednesday, September 03, 2003 7:38 AM >To: [log in to unmask] >Subject: alternate container markup in EAD 2002 > > >Up till now, I've been using the @othertype attribute in the <container> >element in order to accommodate finding aids that assign "box-folder-item" >markup to individual items in collections. Looking through the 2002 DTD, I >see that this attribute has been discontinued. What avenues are available >for doing this sort of markup? In the 2002 Tab Library there is an example >of a finding aid with some item-level description; however, it assumes one >item per folder, so only box-folder numbers are used. Some of our finding >aids describe multiple items in a single container, so each item is >numbered separately. For instance: Folder 1--Item 1, Folder 1--Item 2, etc. > >Has anyone found a way to handle this, in the absence of the othertype >attribute? > >Amy McCrory >Archivist, Cartoon Research Library >023L Wexner Center >(614) 292-0538 >EAD Specialist, Special Collections Cataloging >036 Main Library >(614) 292-8114 >The Ohio State University Libraries >Columbus, OH 43210