1. Introduction

Standardization in the field of document structures, languages and related facilities for the description and processing of compound and hypermedia documents, including:

languages for describing document logical structures and their support facilities

languages for describing document-like objects in web environments

document processing architecture and formatting for logical documents

languages for describing interactive documents

multilingual font information interchange and related services

final-form document architecture and page information interchange

hypermedia document structuring language and application resources

API’s for document processing

ISO/IEC JTC 1/SC 34 has inherited from its predecessors (ISO TC 97/SC 18/WG 8 and ISO/IEC JTC 1/SC 18/WG 8) the responsibility for the maintenance of many important standards that have been hugely influential in the development of the World Wide Web. These standards include ISO 8879 (SGML), ISO/IEC 10179 (DSSSL) and ISO/IEC 10744 (HyTime). These standards still inform work on new standards development within ISO/IEC JTC 1/SC 34, as well as continuing to influence the work of other bodies such as OASIS and W3C.

Here are some significant dates in SC 34’s history:

1984 — ISO TC 97/SC 18/WG 8 formed with ANSI appointed as Secretariat and William Tunnicliffe appointed as Convenor. Its first project was to work on the development of ISO 8879 SGML.

1998-06 — JTC 1/WG 4 was disbanded and a new SC (SC 34) was established with the title of “Document Description and Processing Languages” at the JTC 1 Sendai Plenary.

1998-11 — The first meeting of JTC 1/SC 34 was held in Chicago, USA and Working Group 1 (Information Description), Working Group 2 (Information Presentation) and Working Group 3 (Information Association) were established.

2. Some Background

[Most of the text in this section was contributed by James David Mason, Ph.D., from his private archives. It has been edited for formatting purposes only and to correct obvious typos. Dr. Mason was Former Vice-chairman, ANS X3V1; Convenor, JTC1/SC18/WG8; Chairman, JTC1/SC34.]

This history of the standards committee currently known as ISO/IEC JTC1/SC34 can be traced back to earlier committees in the ISO family back to 1978. It is also inseparable from the history of Generic Markup, which arose in many places in the world of computing, back to the late 1960s.

While this document is ostensibly a history of SC34 and its predecessors, it also examines some of the roots of Generic Markup outside the formal standardization process. Inevitably it also focusses on some of the personalities who influenced the growth of SGML and its applications and successors, such as HTML and XML.

2.1 Before SGML

Generic Markup is one of those ideas that seems to have arisen in many places almost by spontaneous generation simply because the conditions were ripe for it. By the late 1960s computers had enough processing power to manipulate text, and numerous programs were developed that could do more than simply print reports from databases on line printers.

2.1.1 Programmable Formatters and Generic Coding

Among the earliest useful systems was RUNOFF, written by Jerome H. Saltzer in 1964 (http://en.wikipedia.org/wiki/RUNOFF). RUNOFF begat numerous progeny, notably many variants on Digital Equipment Corporation (DEC) systems, which led to nroff/troff on UNIX systems. RUNOFF was also an ancestor of FORMAT for IBM’s System/360. As these systems evolved, they grew beyond simple commands for direct formatting to becoming programmable interpreters of more sophisticated languages.

The troff family of processors (http://troff.org/history.html, http://en.wikipedia.org/wiki/Troff) was begun by Joe F. Ossanna of Bell Laboratories in about 1973; it was rewritten into ditroff (device-independent troff) by Brian Kernighan in 1979 and then into groff by James Clark (of whom, more later) in 1990. Among the most important effects of the development of troff was that it spawned macro packages, some of which are still under development thirty years later. Among the most notable were the -ms macros by Mike Lesk and the later -mm (Bell Laboratories Memorandum Macros) by Dale Smith and John R. Mashey, which supported a generic coding scheme roughly comparable to the capabilities of HTML or the GML Starter Set.

Roughly contemporaneous with the troff family was the development of GML by Charles Goldfarb, Edward Mosher, and Raymond Lorie at IBM, from roughly 1969 on. (Someone else needs to write this section; http://www.sgmlsource.com/history/roots.htm.)

Another influential system in this class was Scribe, by Brian Keith Reid, begun around 1976 and published as his doctoral dissertation in 1980 at Carnegie Mellon University (http://en.wikipedia.org/wiki/Scribe_%28markup_language%29). Scribe was notable for its emphasis on descriptive markup, as well as for its use of parameters, which suggested later SGML attributes.

Probably the most significant of these programmable formatters is TeX, begun by Donald Knuth in 1977, which came to support a full Turing-complete programing language by 1982. (A colleague of mine actually wrote a routine for extracting square roots in TeX as part of a page-layout system.) The best known macro package for TeX is LaTeX, originally written in the early 1980s by Leslie Lamport and still used as a generic coding system by many working in mathematics and the physical sciences.

2.1.2 GenCode (R)

Many credit the start of the generic coding movement to a presentation made by William Tunnicliffe to the Canadian Government Printing Office in September, 1967: his topic—the separation of the information content of documents from their format.

At about the same time, a New York book designer named Stanley Rice was promoting the idea of a universal catalog of parameterized “editorial structure” tags. Norman Scharpf, director of the Graphic Communications Computer Association (GCCA), recognized the significance of these trends, and established a generic coding project in the GCCA Composition Committee, chaired by Tunnicliffe. That project evolved into the “GenCode” (TM) Committee, which later played an instrumental role in the development of the SGML standard. (The GCCA eventually dropped “Computer” from its name, becoming the GCA. After Scharpf’s retirement, the GCA became IDEAlliance. For most of its existence, the GCCA/GCA was affiliated with the PIA, Printing Industries of America, and the GenCode Committee and later WG8 often met at PIA Headquarters.)

Source: ISUG history file

Charles Goldfarb recalls: In 1971 the GCA Annual Meeting was held in Boston and Norm Scharpf, a former IBM Marketing Manager, had inquired as to whether our lab had anything interesting to show off on a site tour. I agreed to demonstrate the InTime prototype (without going into technical details), and to give a paper on “context editing”. (That was heady stuff in 1971: you could actually navigate a file by searching for text strings instead of specifying line numbers!)

Norm invited me to a meeting of the “System X” committee, where I met Bill Tunnicliffe for the first time. There were 8 or 10 of us crowded into a hotel room in Boston, with steak dinners perched on our knees, discussing markup codes. I’m not sure about the technical results of the meeting, but I can say one thing for certain, having benefited from Norm’s generosity in nurturing SGML and HyTime standards activities over the decades since: He’s never fed another committee quite as well.

The GCA continued to work independently of our efforts in Cambridge. System X evolved into the “GenCode(R) concept”, which recognized that different generic codes were needed for different kinds of documents, and that smaller documents could be incorporated as elements of larger ones. GCA and I eventually joined forces in 1978, when development of the SGML standard began.

(Bill Tunnicliffe became the first chairman of WG8, the ISO committee that developed and maintains the SGML family of standards. I mention it, although it is outside the period of this memoir, because Bill passed away on September 12 of this year, at the age of 74. We had a chance to honor him for his contributions in person at SGML ’92. We won’t have that chance again, so I want to thank him here.)

2.2 The Origins of SC34

2.2.1 Organizational Structures

The GCA GenCode Committee continued in existence until the early 1980s, but much of its work transferred to a formal standards organization X3J6. In 1978, the American National Standards Institute (ANSI) committee on Information Processing established a committee on computer languages for text processing, chaired by Chuck Card. Goldfarb was asked to join the committee and eventually to lead a project for a text description language standard based on GML. He enlisted the support of the GCA GenCode committee, which provided a nucleus of dedicated people for the formidable task of developing his basic language design for SGML into an acceptable standard.

X3 was a standards-developing organization chartered by ANSI to handle Information Technology; its headquarters was at CBEMA, the Computer and Business Equipment Manufacturers Organization, a trade organization based in Washington, DC.

In the late 1970s there was no such thing as a personal computer. The programmable formatters from IBM and DEC and those in the UNIX and academic communities ran on mainframes or large minicomputers. In the office environment there were the beginnings of electronic devices for word processing. (The earliest was probably the Friden Flexowriter, whose origins were before World War II: http://en.wikipedia.org/wiki/Flexowriter.) These devices were completely self-contained and completely proprietary. Each manufacturer of word processors in the early 1980s had a closed system that incorporated both the text-processing software and an operating system. Although many of these devices used ASCII encoding for text (a few used EBCDIC), their overall code structure was always closed. Even though many used available computer media (e.g., 8-in. flexible disks), their recording format was also closed.

With the contemporary environment of text-processing as a background, X3J6 began with the assumption that it would have to develop an entire system: an operating system, a text editor, a formatting program on the troff or TeX model, and a unifying language for representing text. That language quickly came to be what was coming out of the GenCode committee.

X3J6 also had an international presence as the “Experts Group on Computer Languages for Processing Text” (EGCLPT) in ISO TC 97, the international committee for which X3 was the U.S. representative. For a time EGCLPT was a WG5 of TC97/SC5 (Programming Languages). The founding chairman of X3J6 was Charles Card, of Sperry Univac. The vice-chairman was Grant Crawford, of the University of Alberta, Edmonton. Larry Beck, then of Grumman Aviation, served as a temporary chairman after the abrupt departure of Chuck Card during the meeting in Phoenix in 1984. The last chairman was Bill Davis, of the U.S. Internal Revenue Service, who was a long-time member of the GenCode Committee.

Contemporaneous with X3J6 was another X3 committee, X3A12, which looked at word-processing systems. In the spring of 1981, ISO TC97 decided to organize a committee for word processing. TC97/SC18 met first in Ottawa; the chairman was The Rev. Michael Bedford, of Burroughs. SC18 initially intended to coordinate with CCITT (Comité Consultatif International Téléphonique et Télégraphique, an organ of the UN’s ITU, International Telegraphic Union).

Like X3J6/EGCLPT, SC18 and CCITT took a comprehensive view of text processing, intending to design a system that not only involved the formatting of text but also telecommunications. Most of the CCITT’s members were national telecommunications authorities, and they were looking for another tariffed protocol to sell to end users. The CCITT members expected to lease out text-processing terminals, much as they leased telephones, and to charge for document interchange. The primary project was for ODA (Office Document Architecture), with a supporting role played by a counterpart to the CCITT MHS (Message Handling System). The initial intent of the SC18/CCITT projects was to be an application of the OSI (Open Systems Interconnect) protocols.

SC18 was divided into five working groups:

WG1, User Requirements – TC97 was interested in seeing that its standards had some relevancy to the market, and SC18 was their test case. There was, however, considerable debate over whether a “user” meant an end user of the system, someone sitting at a keyboard, or a user of the standard, someone developing code to implement it. WG1 eventually turned into a sort of steering committee for SC18, occasionally serving as a referee between other WGs. (Convenorship initially held by Italy)

WG2, Vocabulary – TC97 had an overall vocabulary group, and SC18 was to contribute to it. (Convenor, Prof. Takahashi, Tokyo)

WG4, Data Interchange – WG4 was responsible for translation of the CCITT MHS into ISO. (Convenorship held by the U.K.)

WG5, ODA Lower Architecture – WG5 was responsible for the content to be poured into WG3’s structure (Convenor, Ben Ho, Department of Communications, Canada). Eventually WGs 3 and 5 merged.

Note: I am going into detail about SC18 and ODA because:

SC34 is the successor to SC18 and inherited its work on text processing.

INCITS V1, the U.S. TAG to SC34 is the committee organized because of the formation of SC18.

Although ODA failed in the marketplace, some of the ideas in it had major influence on SGML and later standards.

There are few people left in ISO standardization who were involved in SC18, and someone needs to leave a record of its work.

In November 1981, X3A12 was reorganized into X3V1. The organizing chairman was L. Millard Collins, of IBM, and the vice-chairman Joan Knoerdel, of NIST. The structure of X3V1 reflected the structure of SC18. Roy Pierce, Xerox, was chairman of TG3, and Larry Tate, IBM, chairman of TG5. The other members of TG3 were Chuck Card and myself. I was initially secretary of TG3, then secretary of V1 and by 1984 vice-chairman of V1.

In 1984, TC97 decided to reorganize as a result of seeking cooperation between ISO and IEC, the International Electrotechnical Commission. In the new committee, JTC1 (Joint Technical Committee 1), SC18 initially remained the same. EGCLPT went through several transitions, first as a WG of JTC1 itself, then as a WG of SC22 (Programming Languages), before it was merged into SC18 as WG8. SC8 also acquired a WG9, dealing with user interfaces and ergonomics (primarily keyboards, though for a while also screen icons). With Chuck Card’s departure from X3J6, the first convenor of WG8 was Bill Tunnicliffe, the founder of the GenCode Committee. (WGs 6 and 7 were proposed structures that did not materialize, but their numbers could not be reused.)

2.2.2 ODA

The core of the design of ODA came from a dissertation by Wolfgang Horak at the University of Munich; Horak by then worked for Siemens in Munich and was active in WG3. Horak had a structured view of documents, though his structure was often more about physical artifacts (pages, page areas, text blocks) than the “editorial structure” that drove the GenCode work. As with word processors of that era, there was one foundational “logical” unit, roughly corresponding to a paragraph. ODA documents nonetheless talked about making a distinction between a “layout structure” and a “logical structure” that existed concurrently in a document. It was never clear whether there would be a user facility for defining logical and layout structures, much less a schema language for encoding definitions.

Actual text content was assumed to be ISO/IEC 8859 (the 8-bit international extension of ASCII [ANS X3.4, ISO 646]), along with embedded graphics. At some level, never fully defined, ODA expected there to be a transition between the structured architecture and one coded with control characters, after the manner of the proprietary word-processing systems. WG5 accordingly maintained a close connection to JTC/SC2, which was responsible for coded character sets such as ISO/IEC 8859. They expected to add new control codes for functions like changing fonts and type sizes.

Unlike the GenCode community which was used to editors for raw text (and markup), followed by batch formatters, the ODA developers expected users to have WYSIWYG terminals. Accordingly, they were not concerned with the readability of the interchange form of their documents. ODA chose a binary representation that was initially intended to be an application of ASN.1 (Abstract Syntax Notation One, ITU X.208) because they wanted to make ODA an application of OSI and benefit from its adoption. The ODA data stream, defined as ODIF (Office Document Interchange Format) was to be binary, expressed in type-length-value packages. The packages would have blocks down to the level of the “logical” and “layout” units, then just streams of data, either binary graphics or text with formatting expressed through control codes.

ODA soon ran into the “overlapping structures” problems familiar to the SGML/XML community and resorted to the binary equivalent of stand-off markup. The ODIF standard eventually envisioned an interchange format that began with a header structure, followed by undifferentiated data. The header structure would encode both logical and layout information, with pointers into the data sequence. Whether the data was characters, control codes, or binary graphics was irrelevant because the structural information worked through pointers into the sequence. The only problem was for implementers, who would have to write editors and processors with heavy pointer-management requirements. One result was that no ODA editor ever got beyond the stage of a laboratory prototype.

The reduction of ODA content to a binary ODIF stream essentially removed most of the requirements from WG5, other than maintaining liaison with other JTC1 committees. Before that resolution came about, however, there were several meetings between WG3 and WG5, trying to define the division of responsibility. At a meeting in Toronto in late summer 1985, I brought in several WG8 members, notably Bill Tunnicliffe, Larry Beck, and Charles Goldfarb, to stir the pot some more. Goldfarb gave a particularly powerful presentation on markup of structures. During the presentation, Ian Campbell-Grant, from International Computers, Ltd., London, who was the representative of ECMA (European Computer Manufacturers Association) and general editor of ODA, leaned over to me and asked, “who does this guy think he is, a prosecuting attorney?”, to which I replied, “yes!”

WG3 then moved to Ottawa for its own meeting and to discuss the results of the Toronto meeting. Luke Zeckendorf, from Philips, the editor of ODIF, told me he had decided that ODA needed an SGML representation as well as the binary one: “See, we have these animals called Goldfarbs, and we have to devise some sort of cages for them!” It fell to Goldfarb to devise his own cages; Zeckendorf eventually made him co-editor of ODIF.

The result of attempting to represent ODA in SGML led to two significant additions to WG8’s work: CONCUR and Architectural Forms, though only CONCUR appears in the SGML standard. Architectural Forms were an implicit part of ODIF and did not gain full expression in a WG8 standard until HyTime. CONCUR was obviously a response to ODA’s two structures that attempted to avoid stand-off markup. As is typical of Goldfarb’s innovations, it is a more general design than the original application called for since it purports to represent an arbitrary number of structures.

Architectural Forms evolved because ODA lacked explicit internal tools like schemas. It was apparently intended that the user of an ODA application could design new reusable structures on the fly, much as it is possible to create a new style from existing formatting in many word processors. Accordingly, it was necessary to provide a tool for linking whatever markup might appear in a document to generalized predefined structures.

ODA was never fully implemented. Both DEC and Philips developed demonstration editors, but neither was made into a product. One problem was that each ODA document was a one-time event. Without a schema or stylesheet language or other interchangeable tools for defining reusable structures that could be used across documents, there was little incentive to develop industry-wide standard applications. Another problem was that ODA had hundreds of options to accommodate almost any kind of document event (mostly formatting), and conformance was so complex that it was difficult to tell whether two systems would indeed be able to interchange documents. The closest ODA came to schemas was a set of profiles of capabilities that attempted to specify which of the many options would be used in a particular interchange.

Because SGML was specified in a formal production grammar and ODA was only specified in text I nagged them that they didn’t have a real machine-processable specification. (Zeckendorf and Goldfarb did use BNF to specify ODIF.) The result was a project for a “Formal Specification of ODA” in the form of logical existence proofs. A number of academics poured many hours over several years into this effort without lasting results; it was still going on when SC18 went out of business.

ODA was in many ways the victim of the evolution of software, particularly after the arrival of the personal computer. ODA developers kept attempting to add new features to the system, even though the existing features had not been implemented, down into the mid-1990s. When WG8 started work on HyTime, WG3 started trying to plug in a hypertext module. They did not recognize the full import of the rise of HTML and the Web—or even what those things were. I was sitting next to Steve Price, National Computing Centre, the current WG3 convenor at the SC18 Plenary in Dublin in the summer of 1995. I looked over at his laptop and noticed he was taking notes in HTML: I observed, “I’m glad to see you’ve gone over to the enemy.” He looked at me very strangely, and I said, “you’re making notes about ODA, but you’re using SGML.” He replied, “but that’s this new thing, HTML.” To which I could only answer, “Yes, and it’s an application of SGML.” ODA lingered on for about two more years before the project was killed. ODA has vanished from the world of standards, but it left numerous effects in the work of WG8 and SC34. In addition to being the cause of CONCUR and Architectural Forms, ODA influenced the design of DSSSL and thus of XSL.

2.2.3 WG8 and its Heirs

Today’s SC34 came out of EGCLPT by way of SC18/WG8. For me, this has been a personal journey.

I first heard of X3J6 at the organizational meeting of X3V1 in November 1981. Chuck Card was meeting with X3V1, TG3, and I was talking about my work with “troff -mm”. He remarked that there was another committee working on something based on IBM’s GML, with which I was already familiar. I went next door to an IBM office and got a copy of the DCF/GML manual. I attended my first X3J6 meeting in Phoenix in the spring of 1982. I remember Goldfarb standing at a board, lecturing. Sharon Adler was shouting at him, someone was standing on one of the conference tables, screaming at things in general, and someone else was in a corner of the room, on the floor, withdrawn into a fetal position. At this point, the language, as used in instance documents, already had a shape that would be recognizable today. There was not yet, however, a schema language. The definition of element properties was at that point a tabular presentation, with an expectation that maybe someone would figure out how to parse it.

By 1983, SGML had become even more like the later language. There was a notation for DTDs. There were more delimiters than in the present language (so that one commenter on the draft ISO standard complained of “chicken scratches”). Much of the growth occurred in a marathon two-week X3J6 work session in Phoenix. Goldfarb came in with a draft, which we dissected. Then we started a daily cycle: every night, Charles put in the day’s changes, using a terminal and a 300-baud modem. He stayed up much of the night. Someone in California ran it through DCF (the actual SGML standard is marked up in GML, not SGML) and ran it though an early IBM laser printer, then put the copies on an early-morning flight to Phoenix. The J6 members took the copies to examine for technical changes, while my wife, Bettie, had an editorial pass at it. Sometime in the early afternoon, Charles would emerge, and we would discuss the changes. When evening came, Charles would take the committee’s changes and Bettie’s and start the revision cycle over. At the end of two weeks, most of us were ill. Charles went home and checked into a hospital. Bettie and I were running high fevers. But SGML had become largely the document that GCA published as GCA STANDARD 101-1983, GenCode and the Standard Generalized Markup Language. Over the course of the summer, Bill Tunnicliffe had arranged for SGML to be adopted for use by the U.S. Department of Defense, and nothing has been the same since then.

2.2.4 Early Membership in EGCLPT

X3J6/EGCLPT and their successor organizations felt their success was partially a consequence of their having a different type of membership from most of the other organizations working in the same general area of standardization. The original SC18 and, indeed, most of the reorganized SC18 after the merger of EGCLPT, was mostly made up of vendors (IBM, Xerox, ICL, Siemens, Wang) and telecommunications service providers (e.g., AT&T, British Telecom, Deutsche Telekom) who expected to offer ODA as a service. EGCLPT, in contrast, was made up mostly of end users who were creating something for themselves because such a product was not then available from vendors. Most generic coding projects prior to SGML were user-created, and most came out of research environments. Tunnicliffe’s original project was sponsored by the National Science Foundation. Scribe was a dissertation project. Troff and its macros came out of a research laboratory. TeX was written to support research publishing. Even though GML was developed in a major computing manufacturer, Goldfarb and his colleagues were working in much the same sort of environment as had spawned the other generic coding projects.

The GenCode Committee was made up mostly of end users, and its membership spilled over into EGCLPT.The GenCode Committee had been sponsored by the GCA.The GenCode Committee’s chairman, Sharon Adler, then worked for Boeing Computer Services and was involved in applying Goldfarb’s GML to publishing projects. Though she later moved to IBM, she remained in publishing activities. Bill Davis worked for the Internal Revenue Service, which had many large-scale publishing projects, particularly using GML. Joe Gangemi worked for ROCAPPI, one of the earliest computerized typesetting service bureaus, where he had been working on generic coding as an internal development project. (ROCAPPI stood for Research on Computers for the Printing and Publishing Industries. John Seybold had founded the company with help from GCA to investigate how best to adapt computer technology to the special requirements of publishing. Gangemi had written most of their compsition system.) Lynne Price worked for a number of computer companies, but she came to X3J6 initially as a representative of the TeX Users Group. Larry Beck came from the publishing support group at Grumman Aviation. Kit von Suck represented DEC (Digital Equipment Corporation), a computer vendor, but he came from a publishing organization (where RUNOFF was developed). I represented the in-house publishing organization of a Government research laboratory.

International membership in EGCLPT was similarly based in research and service organizations. Grant Crawford, one of the first members from outside the U.S., came from a university computing organization in Alberta. Han Nonnekes, from Shell in the Netherlands, was in a computer group that supported publishing; like many others, he was an early user of GML. Craig Smith came from a nuclear physics research organization in Germany. Joan Smith came from the National Computing Centre in the U.K. Though NCC was an early supporter of ODA and Joan was once the general editor of that standard, she was a convert to SGML and founded the International SGML Users’ Group (ISUG) in 1984 and made it into one of WG8’s most important liaison organizations. Anders Berglund, a physicist at CERN in Geneva and a user of GML for his publishing activities, went on to develop an SGML publishing system at CERN and later replicated it at ISO Central Secretariat. Anders’ work on SGML at CERN was the initial inspiration for Tim Berners-Lee’s HTML.

2.2.5 The Effects of Joining SC18

In late 1984 and early 1985, TC97 reorganized itself into JTC1 and EGCLPT became SC18/WG8. Because it had been determined that the U.S. would supply the convenor of WG8, Millard Collins offered me the position. I could not get support from my management, and I recommended that Bill Tunnicliffe become the first convenor of WG8. In the spring of 1985 there was a disruption between Tunnicliffe and Norm Scharpf, and Tunnicliffe retired suddenly from both GCA and WG8 (during the SC18 Plenary in Washington). In the fall, Millard Collins again offered me the position (while I was at the WG3 meeting in Ottawa). I was then able to get support, and I remained the convenor through the rest of the history of WG8. JTC1 reorganized again in 1997, and SC18 was disbanded. SC18/WG8 became JTC1/WG4 at the end of 1997 and remained in that position through early 1998. At the end of 1998 the present SC34 was organized, and I became its first chairman, at a meeting in Chicago.

SC18 was not initially pleased to receive WGs 8 and 9. Neither fit well into the ODA-centric program. Goldfarb, Card, Tunnicliffe, and I had been participants in SC18, and Sharon Adler had attended some meetings of V1. However, SGML had already become a DIS (Draft International Standard) under TC97, and the new SC18 was glad to have a standard at that level. (ODA would not achieve that status until 1986.) Where the same company had anticipated in both EGCLPT and the original SC18, there was often internecine strife in the reorganized committee. In particular, Goldfarb and Adler often found themselves at odds with IBM supporters of ODA.

The final ballot on DIS 8879 was completed in early 1986, and the first WG8 meeting I chaired, in Sunnyvale, CA, was devoted to resolving ballot comments. We finished a Resolution document in time for Charles and me to fly to Tokyo for the SC18 plenary. The two major holdouts with negative ballots on SGML had been Germany (DIN) and the U.K. (BSI). Just before we departed for Tokyo, the DIN representative (Craig Smith) and the BSI representative (Joan Smith) prepared documents to their national bodies, indicating that all issues had been met with, so the national body votes should change to approval. SC18 would get its first completed International Standard.

At the Tokyo meeting of SC18, there was little that could be done to stop SGML. Nonetheless, the rest of the X3J6/EGCLPT program of work came under intense pressure. Most of the pressure was political, from the ODA camp. They were unprepared for WG8 to come in with SGML as a competed International Standard at its first SC18 Plenary.

WG8 presented its “Programme of Work”, showing that, with SGML complete, it intended to continue its other projects that had been started under EGCLPT. The most contentious of these was the heir to the original “formatter.” When EGCLPT started, the members thought it might be necessary to create an entire computing environment, of which SGML was only a very public manifestation. Most of the users employed batch formatters with generic coding as an input. Because there was little vendor support for such operations, EGCLPT thought it might be necessary to specify the capabilities of a batch formatter that would accept SGML directly. The ODA party saw this as a weakness in the SGML camp. If they could prevent development of a “standard formatter”, perhaps they could prevent adoption of SGML, even though the standard was complete. Accordingly they raised procedural objections. Such objections had not been possible against SGML because it was already out for final ballot when the merger occurred, but the remainder of WG8’s Programme had not yet gone to ballot and so was open to question. A typical Working Group convenor’s report to the SC18 Plenary lasted about 15 minutes. I was on my feet for more than an hour and a half. Goldfarb and I were the only WG8 representatives in a meeting of nearly 40 supporters of ODA. Charles could not take the floor, so most of the burden of supporting WG fell to me.

WG8 was eventually allowed to proceed with its program, on an interim basis, but the next several years were filled with repeated negotiating sessions with the ODA camp and compromises that greatly slowed down the progress of standards. The ODA camp was caught in a difficult situation itself. ODA had, like the EGCLPT projects, begun in the days of dedicated word-processing systems and telecommunications hardware completely controlled by the service providers. By 1986, when SGML was completed, the personal computer had already made an impact on text-processing systems, and the ability of telecommunications service providers to dictate what sorts of equipment could be connected to their networks was rapidly decreasing. When ODA entered the standardization process, a dedicated ODA terminal provided by the telephone company was still conceivable. In 1986 such a device was already unthinkable. The ODA developers responded to the changing environment by redirecting the intended application of their standard. They addressed themselves towards the capabilities of current word-processing software and the rising field of desktop publishing. However, they lacked expertise in those areas, and the most convenient source of such expertise was WG8, based in the publishing industry rather than in telecommunications. ODA needed the WG8 “formatter” even while they wanted to kill it to hamper SGML.

What came out of the protracted negotiations between WG3 and WG8, which lasted through the rest of the 1980s, was ISO/IEC 10179, DSSSL, a stylesheet language. Even the name of the standard reflects this period of negotiation: Document Style Semantics and Specification Language. This name, which only a committee could have invented, reflected the constraints on the process by which the standard was developed. WG3 insisted that the standard be restricted to “semantics” of formatting, which is what they needed to learn for ODA. WG8, being language developers, wanted a “language”. What WG3 did not understand was that WG8 never actually intended to create a formatting engine. We were largely publishing people, not programmers, and we were primarily interested in a way of specifying the bridge between SGML and formatting engines someone else would build. (Joe Gangemi, one of the GenCode old-timers, had been the primary developer of ROCAPPI’s formatting engine, but he was a printer turned programmer, not initially a computing person. James Clark, who eventually became one of the most important contributors to DSSSL, had written groff, the GNU counterpart to troff, but he was not yet a member of WG8.)

The constraints placed on the development of DSSSL eventually worked to make the developers define the direction of the language more precisely. The stipulation that the language deal with “semantics” ensured that it would be declarative, not procedural. Although the expression language of the W3’s XSL is different from that in DSSSL (DSSSL used Scheme, a dialect of Lisp, which Clark was interested in), the organization of the language retains the division into transformation and flow objects. Most of the DSSSL specification would be comprehensible to a user of XSL, once the notation is understood.

WG8 had two other projects that SC18 allowed to proceed because they were less contentious than DSSSL, while still being needed by ODA. The first of these dealt with the specification of type fonts. The second was for a Standard Page Description Language. WG3 intended simply to accept the output of these projects without involving themselves in the details.

The original ODA was intended for use with monospaced type, such as might be produced by a line printer or daisy-wheel printer. Fonts were, of course, central to publishing operations. The fonts project, which eventually resulted in the ISO/IEC 9541 series of standards, was already begun in EGCLPT. It was unusual for a WG8 project in that it was led by manufacturers and vendors of type fonts, rather than end users. The initial impetus for the project came from makers of laser printers, first Xerox and then IBM. They were joined by digital type foundries like Adobe, Bitstream, Monotype, and URW. Research support came from the School of Printing at Rochester Institute of Technology. Ed Smura, of Xerox, started the project, and Archie Provan, of RIT, provided much of the early technical design. Barbera Beeton, from the American Mathematical Society, provided input on requirements for technical publishing. Yushi Komachi, then at Panasonic, has been a constant presence in the group since the 1980s, serving as its convenor in SC34.

At the time EGCLPT began its work, there was, of course, no such thing as a page description language. Such things were developed only after the development of the laser printer at Xerox. EGCLPT had some notion of standardizing the output of a formatter, but the idea existed only as an item in the Programme of Work, and little had been done with it in 1986. Chuck Geschke and John Warnock, working at Xerox PARC (Palo Alto Research Center) developed InterPress to drive the Xerox printers. The two developers became frustrated with Xerox’s failure to commercialize the product and left to found Adobe systems, where they rewrote the language as Postscript. Geschke came into X3V1 and presented PostScript as a possible candidate for standardization. The Apple LaserWriter, which had come out in 1985, had made PostScript very visible in the marketplace, and X3V1 was ready to support the project. Xerox, which had a large presence in X3V1, woke up and made a counterproposal based on the latest iteration of InterPress. The result was a hybrid project that resulted in ISO/IEC 10180, SPDL (Standard Page Description Language). SPDL was probably most influenced by PostScript, though it incorporated some of the page-independence features of InterPress. Unlike DSSSL, SPDL did not gain commercial applications. Some of its page-management features, however, may have influenced the design of Adobe’s PDF (Portable Document Format). The other effect of the project was that the developers of the standard led the implementation of PostScript on Xerox’s DocuTech printers, and Xerox became an Adobe client.

2.2.6 SGML after the Tokyo Plenary of SC18

WG8 completed the essential resolution of ballot comments on ISO 8879 at its meeting in Sunnyvale and sent the results to the SC18 Plenary in Tokyo. That did not mean the standard was actually completed. All that really existed was the DIS (Draft International Standard) text that had been balloted, the Disposition of Comments document from Sunnyvale, and instructions to the editor. Goldfarb took the whole summer of 1986 to complete the revision and brought that into the WG8 meeting in Luxemburg. At that meeting WG8 did another detailed close reading of the standard, driven largely by Joe Gangemi, Martin Bryan, and Anders Berglund. Only at the end of the meeting was the text in final form. Goldfarb went to Geneva with Berglund, where they ran the files through Berglund’s publishing system at CERN and delivered the final standard to ISO Central Secretariat. It was published on October 15.

It is usually said that the publication was done from SGML source files. What that means some explanation. Goldfarb’s master files were apparently coded in GML, not SGML, because SGML did not exist until the standard was complete. Goldfarb had a GML-based publishing system at IBM—the one he had developed. But SGML allows redefinition of the “concrete syntax” (i.e., delimiters and character sets) in which it is represented, and under those rules, GML could be proclaimed to be SGML, and so it was the SGML was published. (I am not certain at this point how Berglund’s CERN system was configured. It had started as a typical GML system, with his own publishing style. Eventually it became a real SGML system, and he later migrated the system from CERN to ISO Central Secretariat to publish standards from SGML source.) Complete conversion to what most users would recognize as conventional SGML did not occur until Yuri Rubinsky did the transformation while preparing The SGML Handbook (1990).

While the ODA advocates might have wished to derail adoption of SGML, by 1986 they were already too late. Not only had the U.S. DoD approved use of SGML in 1983, by 1986 there were products on the market to support SGML. In 1984, Datalogics, a producer of high-end batch formatting software for high-volume and technical publishing applications, had announced that it would support SGML input. By 1985, Datalogics had released the first SGML syntax-directed editor (and my report to the SC18 Tokyo Plenary had been written using this editor). During the WG8 meeting in Luxemburg, SOBEMAP (Société Belge d’Économie et de Mathématiques Appliqués) demonstrated the parser which they had been contracted to write for the host of the meeting, the publishing operation of the European Union. Mike Cowlishaw, IBM U.K., had written LEXX, the first SGML syntax-directed editor, for the Oxford English Dictionary project at Oxford University Press, also in 1985 (http://en.wikipedia.org/wiki/Mike_Cowlishaw).

Another WG8 project, in which the ODA group had little interest, produced an ISO technical report, Guidelines for SGML Context-sensitive Editors; Cowlishaw and the developer of the Datalogics editor, Jeff Graubart-Cervonne were the primary contributors.

2.3 Other Technologies

2.3.1 EXtensible Markup Language (XML)

In 1996, XML was started as a simplification of SGML. Technically, XML is a subset of ISO 8879 (SGML) including Technical Corrigenda. However, XML was developed in W3C rather than SC 34. Moreover, XML does not normatively reference ISO 8879, but rather defines the syntax and semantics of XML documents without relying on ISO 8879. As a result, XML was recognized as a new W3C technology, although XML was directly derived from SC 34’s SGML.

The shift from SC 34 to W3C was necessary because XML was intended for a different audience. At that time, SGML and SC34 were not aimed at the Web but rather traditional publishing.

XML was successfully developed in W3C. However, while W3C XML Schema was being developed in W3C, significant differences of opinions emerged. As a result, some people joined SC 34 and started DSDL (Document Schema Definition Languages), which includes RELAX NG (ISO/IEC 19757-2) and Schematron (ISO/IEC 19757-3), among others.

2.3.2 Open Document Format (ODF)

Developed by OASIS, this specification was submitted for adoption to ISO/IEC JTC 1 as a PAS submission, with review and maintenance of the ISO/IEC edition being assigned to SC 34. (See 0.)

2.3.3 OOXML

Developed by Ecma International, this specification was submitted for adoption to ISO/IEC JTC 1 as a Fast Track, with maintenance and revision of the ISO/IEC edition being assigned to SC 34. (See 0.)

Since its first meeting in 2009-01, WG4 has met face-to-face three or four times per year, with meetings by teleconference every 4–6 weeks in-between.

From Resolution 2008-04 08:

Resolution 8: Distribution of Final text of DIS 29500

SC 34 requests the ITTF and the SC34 secretariat to distribute the already received final text of DIS 29500 to the SC 34 members in accordance with JTC 1 directives section 13.12 as soon as possible, but not later than May 1st 2008. Access to this document is important for the success of various ISO/IEC 29500 maintenance activities.

SC 34 instructs its Secretariat to issue a call for participation to the SC 34 members and to request ISO and IEC to publicise the existence of WG 4 to encourage participation from all who are eligible.

From Resolution 2008-10 03:

SC 34 notes that Ecma International is designated as the Secretariat by the National Body of Japan.

SC 34 instructs its Secretariat to issue a call for participation to the SC 34 members and to request ISO and IEC to publicise the existence of WG 5 to encourage participation from all who are eligible.

When this WG was disbanded, its active projects were assigned to the newly created WG8 (§5.8).

All SC 34 projects and activities relating to the maintenance of ISO/IEC 26300 OpenDocument Format. Collaboration with the OASIS ODF TC in the maintenance of and other work exclusively related to ISO/IEC 26300, in accordance with the maintenance principles and procedures jointly agreed by OASIS and JTC 1 (documents N 1148 and N 1149). This includes all projects and activities related to ISO/IEC 26300 previously carried out by WG 1 and Ad Hoc Group 3.

SC 34 instructs its Secretariat to issue a call for experts and a meeting notice with draft agenda to the SC 34 National Bodies and Liaison Organizations.

5.7 JWG7 (Joint Working Group 7) – EPUB

Name

Action

NB

Sam Gyun OH and Yong-Sang CHO

2013–, co-convenors
2012-02–2013, co-convenors

KR/KR

2012–02, Group created

From Resolution 2012-02:

SC 34 approves the terms of reference and Convenors of the joint working group for EPUB.

Terms of Reference

This JWG administered by SC 34 is responsible for the maintenance of EPUB Technical Specifications, and for any directly-related projects as may subsequently be proposed.

Note: Korea is expected to submit EPUB3, which is developed by the International Digital Publishing Forum (IDPF), as Draft Technical Specifications via the fast-track procedure to JTC 1.

This JWG carries out its responsibilities in accordance with the publication agreement / memorandum of understanding between IDPF, ISO and IEC.

Note: The work of this JWG will only begin when both the following have occurred: Korea submits the Draft Technical Specifications for EPUB3 via the fast-track procedure to JTC 1 publication; the publication agreement / memorandum of understanding is signed by IDPF, ISO and IEC. The work of the JWG will stop if the Technical specifications are not approved for publication or they are not assigned to this JWG.

Convenors

Sam Gyun Oh (Korea)

Yong-Sang Cho (Korea)

Participation in joint working group and conduct of Fast Track ballot

SC 34 warmly welcomes the participation of ISO TC 46/SC 4 and IEC TC 100/TA 10 in the joint working group and looks forward to submission of the draft technical specification by Korea. SC 34 requests the Convenors and the Korean National Body to provide appropriate assurances that all comments received in the Fast Track ballot will be given proper and fair consideration, whether from JTC 1 members or from other interested parties.

SC 34 Secretariat is requested to obtain agreement on the establishment of the JWG with IEC/TC 100/TA 10 and ISO/TC 46/SC 4 by the time that the draft Technical specifications are submitted by Fast Track.

Further, SC 34 instructs its Secretariat to submit the above information to JTC 1 for approval after the agreement of ISO TC 46/SC 4 and IEC TC 100/TA 10 is confirmed.

5.8 WG8 – Document Processing and Presentation

Name

Action

NB

Alex BROWN

2014-09–, convenor

GB

2014-09, Group created

When WG8 was created, it inherited the active work from WG1, WG2, WG3, and WG5, which were disbanded.

From Resolution 2014 08:

Responsible for providing assistance to Project Editors in completing the following projects under development.

ISO/IEC 19757-3

ISO/IEC 9541-1/AMD1

ISO/IEC 13250-5.2

ISO/IEC 10036/Cor.3

Responsible for assisting Project Editors in other work (corrigenda, amendments or revisions) on the following projects, if the need arises before this WG is closed and if no New Work Item proposal is needed:

ISO/IEC 9541

ISO/IEC 10036

ISO/IEC 13250

ISO/IEC 19757

ISO/IEC 21320

Following completion of current projects and any new work on the above list of projects that arises during the same period, this WG to be closed in accordance with the Directives.

5.9 Ad Hoc Group 1 on ISO/IEC 29500 Maintenance [DISBANDED]

Name

Action

NB

Alex BROWN

2008-04–2008-09, convenor

GB

2008-04, Group created

This group existed for just a short while, after which all IS 29500-related work was assigned to WG4, once it was created.

The passage of ISO/IEC 29500 has instituted a new era of standards activity in SC 34 related to document formats. ISO/IEC 29500 does not represent an isolated phenomenon, since SC 34 is also responsible for ISO/IEC 26300 and for interoperability between these and other projects.

SC 34 envisages the creation of three distinct working groups that meet the needs of:

ISO/IEC 29500

ISO/IEC 26300

Work on interoperability/harmonization between document format standards

and wishes to incorporate existing expertise on these standards.

For these reasons, SC 34 hereby establishes an ad hoc group pursuant to the JTC 1 Directives, clause 2.6.2, for investigating how the first of these groups may be set up most effectively.

Terms of Reference

The terms of reference for the group are as follows:

The task to be completed by the group is to advise its convenor on creation of a document proposing structures and mechanisms for onward work on ISO/IEC 29500. Onward work is defined as:

Maintenance as provided for by the JTC 1 Directives (in particular Section 15 – Maintenance of International Standards)

Handling new work items directly and exclusively related to ISO/IEC 29500 (e.g. creation of new Parts of this Standard or evolution of this standard)

The proposal shall be drafted by the convenor as one or more resolutions (with supporting explanatory material) that may be discussed, revised and adopted by SC 34.

The ad hoc group should consider the following factors in making its recommendations to the convenor:

A new working group should be created in SC 34 for the purpose of maintenance of ISO/IEC 29500 pursuant to Section 15 of the JTC 1 Directives for standards maintenance.

Editors and editing teams should be nominated as well as mechanisms for the nomination of editors and editing teams for ISO/IEC 29500.

Transparency of process, consistent with JTC 1 Directives, is a goal of the recommended process.

Consideration should be given to how Ecma and ISO/IEC versions of ISO/IEC 29500 may be best kept synchronized.

The proposal should recommend ways in which onward work on ISO/IEC 29500 may be carried out in as timely a way as possible, without recourse to the accelerated mechanisms of PAS or Fast Track procedures.

The ad hoc group shall make its proposal to SC 34 for consideration at its plenary scheduled for 2008-10-01, at Jeju Island, Korea. A draft proposal shall be made available to SC 34 one month before the plenary.

The ad hoc group shall be open to participation from all SC 34 members, subgroup members, and liaison bodies. Participants shall be nominated by these bodies to the SC 34 secretariat in the usual way.

The ad hoc group shall be convened by Dr Alex Brown, as nominated by the UK National Body (BSi).

Administration and support for the ad hoc group’s activities shall be provided by the SC 34 Secretariat.

The ad hoc group shall arrange face-to-face, telephone and electronic meetings as required in accord with the provisions of the JTC 1 Directives. The first face-to-face meeting shall take place in early July in London, UK.

5.10 Ad Hoc Group 2 on ISO/IEC 29500 Comment Collection [DISBANDED]

Name

Action

NB

Makoto MURATA

2008-04–2008-09, convenor

GB

2008-04, Group created

This group existed for just a short while, after which all IS 29500-related work was assigned to WG4, once it was created.

From Resolution 2008-04 05:

[Note: This group will focus only on the initial collection of comments on ISO/IEC 29500. The long-term maintenance of ISO/IEC 29500 will be addressed by Ad Hoc Group 1.]

ISO/IEC JTC 1/SC 34 establishes Ad Hoc Group 2 in accordance with subclause 2.6.2 of the JTC 1 Directives, with the following terms of reference:

Definition of the task:

To define and put into operation a mechanism to compile a list of comments on ISO/IEC 29500 received from NBs, liaisons, and the general public.

To publish the on-going list as an open document on the SC 34 website.

Time frame: The collection mechanism is to become operational within 90 days from the end of the April 2008 ISO/IEC JTC 1/SC 34 plenary. Once this is operational, collection will continue until a long-term maintenance process is operational.

Meeting arrangements: Work will be handled primarily by email, with optional telephone conference calls at dates and times to be announced.

5.11 Ad Hoc Group 3 on Maintenance of ISO/IEC 26300 [DISBANDED]

Name

Action

NB

Francis CAVE

2009-03–2009-09, convenor

GB

2009-03, Group created

This group existed for just a short while, after which all IS 26300-related work was assigned to WG6, once it was created.

From Resolution 2009-03 02a:

SC 34 establishes its ad hoc group on Maintenance of ISO/IEC 26300 with the following terms of reference:

to develop a long term plan for maintenance of ISO/IEC 26300 in coordination with OASIS and to present the proposed plan and any other recommendations to the SC 34 Plenary following the next JTC 1 Plenary

to coordinate all activities relating to the maintenance of ISO/IEC 26300 within SC 34, according to whatever detailed procedures OASIS and JTC 1 may agree, until such time as a long term plan is ready to be implemented, when this Ad Hoc Group would be dissolved.

5.12 Ad Hoc Group 4 on EPUB [DISBANDED]

Name

Action

NB

2012-10, AH4 was replaced by JWG7

Makoto MURATA and Yong-Sang CHO

2012-06–2012-10, co-convenors

JP/KR

Makoto MURATA and Yong-Sang CHO

2011-10–2012-06, co-convenors

JP/KR

Makoto MURATA and Yong-Sang CHO

2011-03–2011-10, co-convenors

JP/KR

Makoto MURATA and Yong-Sang CHO

2010-09–2011-03, co-convenors

JP/KR

2010-09, Group created

From Resolution 2010-09 01:

Resolution 1: Establishment of Ad Hoc Group 4 on EPUB

SC 34 instructs its Secretariat to circulate the following resolution to the SC 34 national bodies for a 30-day default letter ballot.

SC 34 establishes an ad hoc group on EPUB of IDPF* with the following terms of reference:

to discuss with IDPF whether their EPUB work should be standardized at SC 34 and to present a plan for such standardization and any other recommendations to the next SC 34 Plenary in 2011 March.

to determine the major stakeholders concerned with EPUB standardization and propose additional liaisons that would enable these stakeholders to be represented in any standardization process.

SC 34 accepts the report of AHG 5 (see N 2086) and thanks the members of AHG 5 for the timely completion of their work.

The Executive Summary: AHG 5 held three teleconferences and two face-to-face meetings, attended by representatives from eight different national bodies and liaison organizations. AHG 5 recommends folding SC 34 WGs with minimal active work – WGs 1, 2, 3 and 5 – into a single new WG tasked solely with completion of those active work items. No changes are recommended to SC 34’s scope.

5.14 Advisory Group on SC 34 Future Directions for Work

Name

Action

NB

Sam Oh

2015-09–, convenor

SC 34 Chair

2015-09, group started

From Resolution 2015 20:

Resolution 20: Establishment of Advisory Group on SC 34 Future Directions for Work

SC 34 creates an Advisory Group on SC 34 Future Directions for work. SC 34 Secretariat is instructed to circulate proposed terms of reference by the SC 34 Chairman for approval and call for participation to the SC 34 national bodies and liaison organizations.

6. Projects without Working Groups

SC 34 itself is directly responsible for the following projects, which have no home WG