--- "Fox, Michael" <[log in to unmask]> wrote:
> Good afternoon,
> Let me offer a little background regarding this matter.
> 4. The data context for <date> which is generic and <unitdate>
> which has a very specific meaning are very different. With
> <unitdate>, label is used as the word suggests- for the
> specification of a display constant that precedes the text.
> <date> does not "stand alone" in the same way but is typically
> embedded in other text and does not usually have any need for such
> a print constant. If some display is needed, the type attribute
> may be employed.
What disturbs me about this answer (though it is one I have heard and
read before), is that the suggested alternative completely
contradicts the whole argument concerning the use and inclusion of
the label attribute.
Why would we suggest that people use @TYPE when they obviously have
@LABEL information? (Hence the request for @LABEL attribute.)
Further, given the context for the element is different, the data is
not. The datatype is a date. Therefore, I would suggest that the
following needs to be done:
1. The DTD should be consistent in enumerating values for the
attributes of these two elements.
2. We should never suggest that @TYPE be used as a replacement for
@LABEL in this case. Rather, the values enumerated for UNITDATE
should be used here also.
If we think of the datatype being coded, we can be consistent about
suggesting alternatives for coders in these situations. Personally,
the inconsistency of attributes when the datatype is the same,
presents unnecessary complications when converting databases to EAD
Library of Congress
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around