In the better late than never category, I've tried to think of any problems
with this
proposal and can't, except the general caveat that it *is* possible to take
generalization to an absurd extreme, however in this case it makes sense to me
to go for a general solution over a specific one since I agree that there
will be
other checksum algorithms and we shouldn't make invalid presumptions.

Could we, pehaps, have an optional attribute of checksumtype, and if that
attribute is missing, but there is a checksum, assume it's an MD5?

And what on earth would the benefit of a checksum create date be?


At 09:57 AM 3/5/2002 -0500, Robin Wendler wrote:
>One of the general questions that came out of the recent
>(and soon to be documented, I swear) meeting on technical metadata for
>audio was about the METS <checksum> attribute of the <file> element.
>Right now, this is defined explicitly as MD5, but there are now and
>undoubtedly will continue to be other checksum algorithms in use. We were
>wondering whether it would be better/possible to generalize this in METS,
>providing for the checksum type, value, and create date. It seems better
>to raise this now, rather before we hit the big Version 1.0.
>What do others think about this?
>-- Robin
>Robin Wendler  ........................     work  (617) 495-3724
>Office for Information Systems  .......     fax   (617) 495-0491
>Harvard University Library  ...........     [log in to unmask]
>Cambridge, MA, USA 02138  .............

MacKenzie Smith
Associate Director for Technology
MIT Libraries
Building 14S-208
77 Massachusetts Avenue
Cambridge, MA  02139
[log in to unmask]