Maximising productivity for reviewers and editors when publishing standards and specifications for W3C

“The advanced, patented technology built into XML Compare enabled it to deal accurate, highly structured XML text, which was particularly impressive.”

Norman Walsh

XML Standards Architect

Productivity ⬆

during the revision process when working on new specification

Errors ⬇

as changes were instantly identified with precise accuracy

About Norman Walsh

Norman Walsh is an experienced technologist with a deep understanding of markup technologies, the standards development process, writing, and software engineering. He specialises in standards development, markup technologies such as XML and DocBook, XML processing (XPath/XSLT, pipelines, etc.) and other web technologies.

Products Used

XML Compare

Background

The W3C

The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web. Founded in 1994 and currently led by Tim Berners-Lee, the consortium is made up of member organizations that maintain full-time staff working together in the development of standards for the World Wide Web. As of 4 December 2021, W3C had 455 members. W3C also engages in education and outreach, develops software, and serves as an open forum for discussion about the Web.

We spoke to Norman Walsh, currently a Senior Software Developer at Saxonica Ltd, but previously an XML Standards Architect at Sun Microsystems where he represented Sun on international standards committees at the World Wide Web Consortium (W3C), the Organization for the Advancement of Structured Information Standards (OASIS), and the Java Community Process (JCP). Positions he occupied included:

  • Elected member, W3C Technical Architecture Group.
  • Chair, W3C XML Processing Model Working Group.
  • Co-chair, W3C XML Core Working Group.
  • Chair, OASIS DocBook Technical Committee.
  • Specification lead for JSR 206: The Java API for XML Processing (JAXP).

The Challenge

Labour-intensive revision

The challenge, in writing specifications and standards, was to ensure that reviewers and editors could easily see what had changed with each revision and could therefore all work with the same version.

Norman explained that each specification, for XSLT for example, was written and published by a Working Group consisting typically of 15 members consisting of 3 editors and 12 reviewers. The editors produced the standard, working collaboratively, and the reviewers approved each revision. The standards were written in XML (sometimes DocBook), and published in HTML. While the draft standard was being produced, the editors each contributed several revisions per day and the reviewers had to approve these revisions.

Initially, this process was carried out by hand, but this was slow, laborious, and prone to error. Simple line-by-line comparison cannot cope with the structure of XML, so some tools were hand-coded and used to detect and identify changes. However, these tools were quite unsophisticated and could not cope with complex changes in the structure and content of the specification XML. This led to inaccuracies and the necessity for manual checking with its associated impact on timescales and resources.

The Solution

Save time, show only change

Once it was realised that manual methods and hand-coded tools were not up to the job the XML Process Model Working Group looked around for an automated solution that would satisfy their requirements. After hearing about DeltaXML at conferences, seminars, and other events Norman obtained a trial evaluation licence for XML Compare and tested it in the working environment. This trial was successful, so Norman decided to integrate DeltaXML’s XML Compare product into the Group’s existing workflow. Norman was particularly impressed with the advanced, patented technology built into XML Compare enabling it to deal accurately with highly structured XML text.

XML Compare

XML Compare was used to identify changes made by the editors and to produce difference files so that reviewers could comment on these changes while being confident that they were commenting on the latest version. The document file for a single standard has a typical size of 1-5Mb and, during editing, several revisions were made each day. So, manually identifying and checking changes would have been extremely laborious and time consuming.

This Working Group produced a total of up to 20 specifications, each involving hundreds or even thousands of revisions. An example can be seen at: https://www.w3.org/TR/2010/PR-xproc-20100309/diff.html.

The Results

Waiting no more

  • All editors and reviewers saw specification changes immediately they were made
  • Advanced, patented algorithms produced fast, accurate comparisons of structured content
  • Significant increase in productivity during the editing/reviewing process
  • Critical changes could be identified, and unimportant changes ignored
  • Vastly reduced errors and inaccuracies (essential within an international standards environment)

The use by this Working Group of XML Compare and DocBook Compare streamlined the process of producing specifications and standards, ensuring that editors and reviewers could work as efficiently as possible. The reviewing process was more accurate, more timely and used scarce resources more effectively.

“XML Compare was used to identify changes made by editors and produce difference files so that reviewers could comment on these changes while being confident that they were commenting on the latest version.”

Norman Walsh

XML Standards Architect

Let’s Deal with Change

DeltaXML’s products are used throughout the world, from SMEs to global enterprises. Our comparison and merging software transform the way our customers handle change in their XML documents, XML data and JSON files. If the above story resonated with your own challenges get in touch with us by either booking a demo or filling in our contact form.

Related Stories

XML in Publishing: The Challenges and Opportunities of Change in XML Documents