The Case for Living Documents Maintaining Approved Document

The Case for “Living Documents”: Maintaining Approved Document Updates between Print Cycles Dorothy J. Hoskins Atypon Tristan Mitchell Delta. XML Ltd May 19, 2019

How can book publishers meet users’ needs for timely updates? 2

The Living Document scenario • Long development cycles between print editions are problematic for fast-paced web content delivery. • Official updates between print editions provide new, subscription-based revenue opportunities. 3

The print cycle is long • Years may elapse between print editions. • First edition: 2009 • Drafts • Second edition: 2017 https: //standards. globalspec. com/std/1198111/aiaa-s-121

Older editions may no longer be available https: //standards. globalspec. com/std/1198111/aiaa-s-121

Internal systems may track the updates

2009 edition From AIAA’s Electromagnetic Compatibility Requirements for Space Equipment and Systems (2009, 2016 draft and 2017) Copyright AIAA 2017 edition Comparing pages in two versions is difficult

2009 edition Mock 2016 draft 2017 edition Comparing pages in more than two versions is even more difficult From AIAA’s Electromagnetic Compatibility Requirements for Space Equipment and Systems (2009, 2016 draft and 2017) Copyright AIAA

Living Documents Meeting users’ ongoing needs 9

A Living Document highlights updates

V 1. 0 V 1. 1 A Living Document meets users’ needs over time Each version can have its own popup with interactive controls

V 1. 0 V 1. 1 A Living Document meets users’ needs over time Each version can have its own popup with interactive controls

V 1. 0 V 1. 1 Usability Different formatting displays additions, deletions, and changes

V 1. 0 V 1. 1 Accessibility Different formatting displays additions, deletions, and changes

Publisher benefits • Increased product value with new, subscription-based revenue models • Improved user experience and increased engagement over time • Transparent editorial process makes changes auditable • Users get important update information as they need it 15

Key requirements • Enable publishers to stay current with the industry • Maintain content delivery quality and usage stats • Avoid interference with subsequent print editions • Provide explicit, detailed information about official changes • Facilitate user control over content comparisons 16

What makes a good comparison? The XML comparison tool • A deep-structure XML comparison that locates changes anywhere in two or more versions • Document the changes in the element names, attribute values, and element text 17

What makes a good comparison? • Collapse multiple whitespace characters • Attribute order change does not trigger tagging • Avoid ID duplication to preserve ID uniqueness • Avoid element duplication where content model permits only one occurrence 18

Comparison Demo Tristan Mitchell Delta. XML Ltd. 19

Updates in JATS/BITS Implementing changes in the standards 20

Suggested BITS update elements • Top-level metadata: The <update-history> in book- or book -part metadata, containing: • One or more <update-wrap> in which are found the BITS <event> with the version name and date, <contrib-group> and <notes> • A new element <update-status> in <update-wrap>, for values that are publisher-determined. 21

Suggested BITS update elements • Local tagging: The <update-text. Group> containing one or more <update-text> elements, delineating the exact XML change locations. 22

Suggested BITS update elements • “Required” locally in <update-text. Group> structure: @compare Holds label values for versions compared 23

Suggested BITS update elements • Local overrides to global values in <update-wrap> • @update-type With constrained values (new/added, deleted, changed, unchanged) or free text and “expected” values. • @update-status Similar to JATS date/@date-type, would use free text values (ie. “editorial, ” “suggested, ” “recommended, ” and “approved”) formatting override. 24

Suggested BITS update elements • Local overrides to global values in <update-wrap> (cont’d. ) • @update-date In ISO date format, which date has meaning to the publisher • @update-editor (of type IDREF) Refers to participant in the update decision for that element • @update-display For an update that needs formatting override. 25

Considerations for JATS/BITS • What does this document “in between print editions” need to store in the document tags? • Philosophically, when does an update require a new DOI? • For multiple updates between print editions, what should be deposited to Crossref, and when? 26

Considerations for JATS/BITS • Backward compatibility with current BITS DTD • Update attributes, local update elements, and <update-history> structure additive. 27

Next steps • Should attributes and elements be added to BITS and NISO STS (not JATS)? • The update attribute set and element structures to be proposed to BITS committee • Contact Nikos Markantonatos, nikos@atypon. com 28

Discussion Dorothy Hoskins Nikos Markantonatos Atypon Tristan Mitchell Delta. XML Ltd. 29

More details on comparison issues • Common problems that arise with the comparisons of complex XML: • Duplicate IDs: Maintain uniqueness between ID and RID attributes 30

More details on comparison issues • Common problems that arise with the comparisons of complex XML: • Single-occurrence elements: Adjust output transform for non-repeating elements 31

More details on comparison issues • Common problems that arise with the comparisons of complex XML: • Selected element differs in some version where choice is permitted in content model 32

More details on comparison issues • Common problems that arise with the comparisons of complex XML: • Formatting-type elements that should be semantic (e. g. , using p/b in place of sec/title) 33

Sometimes the changes are not intuitively tagged. Here, “Electro-Explosive” has been changed to “Electrically-Initiated Explosive. ” Merge results: XML tagging

Sometimes the changes are simply hard to see. Here, “ 464 A” has been changed to “ 464 C” inside a sentence. Merge results: XML tagging

Contacts Nikos Markantonakos, nikos@atypon. com Dorothy Hoskins, dhoskins@atypon. com Tristan Mitchell, tristan. mitchell@deltaxml. com 36