Print

---

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