Let me clarify a few things about my earlier posting
concerning a style attribute. First the examples I
listed for style=0, style=1, etc., were for illustrative
purposes only. I didn't mean to imply that there would only
be 3 styles and no more. I also didn't mean to suggest
that each finding aid needed to conform to a predefined
style. If you have a legacy container list that is unique
as far as its layout style is concerned, it should definitely
be marked up as is. Don't set the style attribute. You'll
need to create your own stylesheet for it and you may not be
able to use applications developed by other institutions
but that's what we're doing currently. Also, the style
attribute has nothing whatsoever to do with how the container
list should be displayed (perhaps "style" is the wrong word
for the attribute after all). It's not intended to specify
that series names are to be 24 bold Times Roman, or that
the first unitloc should appear in a column 100 points wide
and that the second unitloc should appear in another column
also 100 points wide. This is what stylesheets do, not my style
attribute.

The style attribute would be a signal, or a warning to a
processing application of what it should expect when processing
a container list. It describes to the application, for example,
how many unitlocs (or unitids) each component of the container
list will have (maximum) and in what order they appear. This
information is critical in any sgml application and in stylesheets
as well. If requested, I can give a detailed example of how an
sgml application could use this information to perform its function
and how that function is almost impossible without it.

I have noticed in the finding aid world that a certain few
container list formats are very common and in use in hundreds
of repositories. For example it is very common to see a container
list like this:

Box     Contents
1       Miscellaneous Letters
             Incoming
2            Outgoing
                 1947-1963
3                1964-1970

If you have a container list layed out like this then mark
it up like this and assign it style=1.

Another very common layout is two unitlocs followed by a unittitle:

Box   Folder   Contents
1     1        Miscellaneous Letters
      2           Incoming
2                 Outgoing
      1              1947-1963

Let's mark up the container list exactly this way and assign
it a style number of 2.

Container list for rare items and oral histories, etc., tend to
have less of a list-like structure and have their own unique
layout, let's give those a style number. I am not suggesting
to Richard Higgins that he try and force his container lists
into one of the available style numbers, he'll simply mark
it up as it is and won't assign a style number to it at all,
or if he has a lot of container lists with that same layout
he could submit it to the master list of styles if he chooses.

Style numbers would have a great benefit on markup training
and EAD documentation. An archivist would consult the master
list of styles, decide which style (if any) matched her
container list and turn to that section in the manual for
precise instructions and examples of how to mark the container
list up. Special markup tools could be created (similar to the
online web templates we use here at Berkeley) that would
facilitate marking up of the container list. Select a style
number and a predesigned spreadsheet would pop up and allow
the archivist to fill in the fields exactly in the order she
pleases. I repeat yet again, if no style number matches a
particular container list layout, the archivist is on her own
as is currently the case. She will need to come up with her
own method of marking up the container list and she will have
to prepare her own stylesheet. She should not fill in any style
number at all. When I create an EAD application I can advertise
that it supports styles 0 through 14, say, and an archivist can
see that and know whether it will work with her finding aids
or not.

Let me reiterate, since my earlier message was so clearly mis-
understood, that it is VERY useful for an application to know
exactly how many unitlocs, maximum, it should expect to find
in a <c> and what order they are in with respect to the other
elements of the <c> before it begins trying to process it. This
is the sole purpose of the style attribute.

Alvin Pollock
Finding Aid Conversion Specialist
Electronic Text Unit
UC Berkeley Library