Roy Tennant再一次在《图书馆杂志》(Library Journal)上声讨MARC(机读目录)的复杂性,7年前他就呼吁让这个标准死掉。MARC是图书馆领域的数据格式标准有30多年的历史,下面是来自维基百科的描述:
MARC is an acronym, used in the field of library science, that stands for MAchine-Readable Cataloging. The MARC standards consist of the MARC formats, which are standards for the representation and communication of bibliographic and related information in machine-readable form, and related documentation. It defines a bibliographic data format that was developed by Henriette Avram at the Library of Congress beginning in the 1960s. It provides the protocol by which computers exchange, use, and interpret bibliographic information. Its data elements make up the foundation of most library catalogs used today.
源文档 <http://en.wikipedia.org/wiki/MARC_standards>
而Roy Tennant两次发难的原因很简单:MARC格式中有相当数量的字段、子字段是完全没有使用的或近乎全没有使用的。
像大多数过度设计系统一样,Marc标准的设计复杂性来自于"预测未来":
Roy Tennant表明立场,他是“对事不对人”,他提醒大家:"MARC是由一些善意人士开发的,他们在这个格式上努力工作多年,就是为了预测我们在未来的需求。"那么这种在"预测未来"的努力效果如何呢?不必要的复杂性让我们的系统变得不必要的复杂,我们的系统继而又变得不必要的昂贵并且不必要的难于使用。复杂性甚至从输入数据就开始了,我曾经有一段时间从事Marc文件的处理和生成,精确到字节和数据位的格式要求让人不胜其烦。不幸的是采用这个标准的系统都要面临这种复杂性。
既然做出了预测,下一个问题是:预测对了么?Roy Tennant给出了两个事例:1.一些领域专家在推动建立新书目标准 2.过去几年间我们使用数据的方式发生了一些变化 而这两件事都提到了MARC无用的复杂性,MARC要么做出变革要不被替代。答案不言而喻。
这里给我们的警示就是要对系统的复杂性进行管理,避免开发出瑞士军刀式的系统。那我们还要不要考虑未来呢?怎么避免过度设计?我觉得《.Net设计规范》从框架设计的角度,给出了一个比较理想的答案:
1.简单性是一个框架必备的品质,设计师需要在功能强大和简单中间做出平衡
2. 考虑未来发展是双刃剑:一方面以"万一"的借口增加复杂性,一方面可以避免设计随着时间流逝而贬值。这里做权衡的方法是问自己一个问题:最终的决定会对框架将来的发展有怎样的影响?
一个正面的例子:XML
在被MARC困扰的时候我就想到了XML,XML成功可以从它的最初设计目标窥见一斑:
总结
MARC无用的复杂性让业界承受了不必要的负担,提示我们要对系统的复杂性进行管理,不做过度设计。这里可借鉴的方法是:平衡强大与简单,考虑未来关注影响。XML的设计是一个成功的典范。
Roy Tennant文章链接:The Unused Complexity of MARC - Tennant: Digital Libraries - Blog on Library Journal