Death from complexity

Roy Tennant once again described the complexity of Marc in Library Journal, and called for the standard to die seven years ago. Marc is a data format standard in the library field that has been in the history for more than 30 years. The following is a description from Wikipedia:

 

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 1960 s. 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.

Source Document

 

Roy Tennant's two difficulties are caused by the fact that there are a considerable number of fields and subfields In the MARC format that are completely unavailable or almost completely unavailable.

 

Like most over-designed systems, the complexity of Marc standards comes from "predicting the future ":

Roy Tennant stated his position as "not right". He reminded everyone: "Marc was developed by some kind people who have worked hard on this format for many years, this is to predict our future needs. "So what is the effect of this kind of effort in" predicting the future? Unnecessary complexity makes our system unnecessary, and our system becomes unnecessary expensive and difficult to use. Complexity even begins with the input data. I have been engaged in the processing and generation of Marc files for a while, and the format requirements precise to the bytes and data bit are quite annoying. Unfortunately, systems that adopt this standard face this complexity.

Now that we have made a prediction, the next question is: is the prediction correct? Roy Tennant provides two examples: 1. experts in some fields are promoting the establishment of new Bibliography standards. 2. there have been some changes in the way we use data over the past few years, both of which refer to the useless complexity of Marc. Marc either makes changes or is replaced. The answer is self-evident.

 

The warning here is that the complexity of the system should be managed to avoid the development of Swiss Army Knife-type systems. So do we have to consider the future? How can we avoid excessive design? I think the. Net Design Specification provides an ideal answer from the framework design perspective:

1. Simplicity is an essential quality for a framework. Designers need to strike a balance between powerful functionality and simplicity.

2. considering future development is a double-edged sword: on the one hand, increasing complexity with the excuse of "in case", on the other hand, it can avoid design depreciation over time. Here, we will try to ask ourselves a question: how will the final decision affect the future development of the framework?

A positive example: XML

When Marc was troubled, I thought of XML. XML can be seen from its initial design goals:

1. XML should be used on the Internet for ease of understanding
2. XML supports a wide range of diverse applications
3. XML should be compatible with SGML
4. Writing and processing XML should be very simple
5. Select as few features as possible in XML, ideally zero
6. XML should be easy to read
7. XML design should be completed very quickly
8. The XML design should be rigorous and concise
9. XML files should be easy to create

 

Summary

Marc's useless complexity puts the industry at an unnecessary burden, prompting us to manage the complexity of the system without over-designing it. The following methods can be used for reference: balance between power and simplicity, and consider the impact of future attention. XML design is a successful example.

 

Roy Tennant article link: the unused complexity of Marc-Tennant: Digital Libraries-blog on Library Journal