Over the last year, during the preparation of instances for our
OpenText server, I had to create a short list of
"Files that refuse to index" - suffice it to say that
this was also known as "The Headache List."
I parsed, examined, and compared the files on this list,
but was never able to figure out why OpenText refused
to index them...until now.

As serendipity has it, I stumbled across an important
error that will pass most parsers, but will trip up OpenText.
In marking up an EAD instance, there often are very long character strings
that must be broken by line wrap, or soft return, depending on the software
you are using.
Thus, it is not uncommon to have tags that wrap from one line to the next,
such as the <extref> tag in the following example:

---------------------------
<did><physdesc><extent>EXTENT<lb>
Total Boxes: 8<lb>
Other Storage Formats: oversize<lb>
Linear Feet: 6.0</extent></physdesc></did><note><p><extref
ext.ptr="http://www.library.yale.edu/beinecke/manuscript/copyrite.htm">
Copyright &copy; 1992 by the Yale University Library.</extref></p>
<p>
-----------------------------

However, it seems that OpenText will allow some tags to be broken, but it
has a problem with other *crucial* tags. I discovered that all of the files
on my "refuse to index" list shared the same characteristic, which was that
the <archdesc> tag was broken between two lines as in the following example:

--------------------------
</titlepage></frontmatter><findaid><archdesc
level="collection">
-------------------------

It is important that this tag be complete on one line, or OpenText will
throw out the file.
I haven't discovered any other specific tags that are as delicate, but I
suspect that any
high-level tag might cause a similar problem.

I hope this helps anyone working with EAD and OpenText.
You might not need this information today, but do store it away...

Timothy Young
Archivist
Beinecke Rare Book and Manuscript Library
Yale University
New Haven, CT  06520
(203) 432-8131

p.s. OK, Not *all* of my files on the "refuse to index" list were
completely fixed by this procedure. I still have *one* that refuses to behave,
despite the <archdesc> fix, but that's another mystery to be solved.