John, you raise some good points...in institutions that don't have
sufficient technical support staff and just send their finding aids off
to someone else to deal with, format specific encoding could be a
headache. In our case, we have three versions of every finding aid. One
that is for our "internal" use (contains information for staff view
only) and a "public" version for our website and a "public" version for
our consortium website. All of our finding aids are pre-processed via
several XSLT stylesheets before they are posted on our website or are
sent off to our consortium website: empty elements are stripped out,
along with any elements encoded audience="internal" (information that
the public should not see) and any consortium-specific required encoding
is inserted. The transformation of CDATA formatting occurs at this
point, so in our case, this is a non-issue. I definitely would call
this "reuse", but it does require some internal processing whereas your
approach doesn't. In this way, yours in more interoperable, but ours is
easier to encode :)

I would definitely recommend your approach when this type of
pre-processing is not an option for people.

Mark



John Harrison wrote:

> If your motivation for using EAD is reuse and interoperability, then any
> format specific encoding in the CDATA of elements is not a good thing.
>
> I should probably explain that my job is to develop software to search,
> retrieve and deliver EAD finding aids (from over 100 institutions) via
> the web. Hence any unusual, or institutional specific encoding causes me
> a major headache, which is why I'm so against this approach.
>