TECHNICAL PAPER

Representing Changes in Open Document Format

Sponsored by NLnet on behalf of the OpenDoc Society, this paper describes a change tracking format developed for OpenDocument. The format described provides a way of representing successive changes or edits to an XML document, typically, in one or more editing sessions.

Helping to represent even the most complex change

The delta format is not designed as a general delta format for any XML, but rather one that is suitable for document editing. The main implication of this is that the content (typically text) takes priority over the structure (typically paragraphs, tables, text decoration) in terms of changes. An editor does not want to see change to content when he has only changed the structure or styling.

Even an atomic change should have a simple, intuitive, and localised representation within a document. Can this be achieved for representing change for OpenDocument?

Read this technical paper to:

  • Review the additional markup needed for representing change in an easy manner.
  • Review what is meant by ‘atomic change’ and the importance of representing these changes.
  • Explore examples of how these changes would look represented within real XML.

A single action by an editor may generate changes in a number of different places in the document. For example, a global change or ‘replace all’ will generate changes throughout a document, or deleting a column in a table will generate several disjoint changes in the underlying XML representation.

Related Media

CALS tables are used in many technical documentation standards. There are OASIS specifications for CALS tables which include a number of semantic rules to ensure table validity. This paper reports on some of our experiences with CALS table processing and validation.

With the help from DeltaXML’s XML Compare toolkit, Wrycan delivered a solution which integrated XML Compare with their Content Base product. This allows NFPA to manage all their content in a single repository, adding automated comparisons in a product-agnostic form.

JSON is now a widely used format for data both in web applications and more generally. However, systems and APIs that exchange JSON haven’t been able to take advantage of tracking tools. Can this be helped by processing JSON as XML?