Submission and Peer Review

ACS Pubs follows the classic scholarly publishing model for accepting manuscripts: an author writes a manuscript and submits it to a publisher as a candidate for publication; the publisher arranges for a "blind" review of the paper by peers; and finally the journal's editorial office makes a decision whether to accept or reject the paper for publication.

In addition to Journal articles, book chapters are also handled this way by ACS Pubs, although the book chapter authors are invited to submit their content based on the book's specific topic.

ACS makes use of the ManuscriptCentral system, from ScholarOne (2), to handle submission, peer review, and Editorial Office operations for both Journals and Symposium Series Books. Article and chapter content is uploaded by the author to the ManuscriptCentral system in various formats, predominately using MS-Word, although a percentage reflects other formats such as LaTeX. A PDF of the submission is generated by ManuscriptCentral to facilitate peer review and production.

After acceptance for publication by the Editorial Office, ManuscriptCentral automatically transfers the manuscript's content and metadata to the ACS Pubs production workflow system, usually within minutes of acceptance (3).

XML Production

The production process for ACS' Journals and Books uses an "XML First" approach in which the content is converted to XML as early as possible in the process. This allows the XML file to be the version of record for all subsequent editing, page composition, and online delivery stages.

XML Conversion. Once in the ACS production workflow system, the first step in the XML production phase is conversion of the author's submitted manuscript content to XML. ACS Pubs utilizes external vendors to convert the author's content into XML. The process of requesting and receiving converted files is also highly automated, with the manuscript content automatically packaged and delivered to the conversion vendor within minutes of entering the XML production workflow. In parallel, while the manuscript text is converted to XML, any associated artwork or media from the author is also extracted and prepared for publication.

After the conversion vendor has completed its XML conversion work, the ACS Pubs production workflow system receives the converted XML content and automatically routes the manuscript to a queue where it awaits editing by a Technical Editor.

Technical editing. The journal article or book chapter then enters the Technical Editing phase, consisting of three distinct phases:

1. Automated Pre-Editing

2. Technical Editing

3. Automated Validations and Post-Editing

Because the Technical Editing staff is highly skilled and focused primarily on providing scientific and semantic enrichment, ACS Pubs has automated the more routine XML updates in the automated Pre-Editing stage, before the article or chapter is presented to the Technical Editor. Thousands of automated edits made at this stage include actions such as normalizing British American spelling to American English and adding metadata tagging. Likewise, after the Technical Editor completes his or her work on the paper, automated post-edits and validations take over to further condition the XML content for composition and eventual delivery.

At this point in the process, we have a complete "XML package" for the given article or chapter: a completed, edited XML file with accompanying graphics, media, and supplemental material.

Page Composition and Review. After the "XML package" is readied, an initial "proof PDF" is composed from the XML in preparation for proofing. The composed PDF is produced by a composition vendor where the requests to, and responses from, the vendor occur automatically at the direction of the ACS production workflow system.

For journal articles, a "proof package" is automatically packaged and delivered to the "proof review author" (who was identified during the manuscript submission process) via ACS' proof delivery site. Book chapters receive an ACS internal review only. Any required manuscript changes are made to the "XML package" as specified by the reviewer.

After the proof is approved, a publication-ready PDF is composed in anticipation of online distribution.

See the following figure for a diagram of the overall process flow.

Fig. 1

Process Flow for ACS Journals.

Distribution and Delivery

The journal and book processes diverge somewhat in the distribution and delivery phase.

Technologies at a Glance

Tagset vs. Schema

For the purposes of this paper, we differentiate between the terms "tag," "tag definition," "tagset," "module," and "schema" as defined below.

• Tag: an instance of user-defined XML markup: an element, attribute, named entity, etc.

  For example, <citation> is a tag, and the "citation-type" attribute within <citation citation-type="journal"> is also a tag.

• Tag Definition: the specific coding within a DTD or XSD that declares the name of the tag, what type of content it may contain, etc.

  For example, the following simplified DTD tag definition declares a "citation" tag, and defines that it allows two or more child tags:

       <!ELEMENT citation (author+ , source)  >

• Module: a way of logically organizing tag definitions, primarily to allow reuse of these tag definitions for multiple schemas. Related tag definitions are often grouped together and stored within larger chunks that we will call "modules" (5). The use of modules stands in contrast to listing all tag definitions within a single DTD or XSD file. These modules may also be called "entity files" or "include files." The process of determining how tag definitions should be grouped into modules is beyond the focus of this paper.

  For example, if both a Book and a Journal schema wanted to share the same tag called "citation," they could both reference the same "citation" module that contains all of the necessary tag definitions to completely represent a citation.

  Within file citation.ent, we might find all tags related to our simple citation:

       <!ELEMENT citation (author+ , source) >
       <!ELEMENT author (#PCDATA) >
       <!ELEMENT source (#PCDATA) >

• Tagset: a collection of related tag definitions, usually stored within a set of interrelated modules, that provides a complete XML vocabulary for a given application. A tagset includes a comprehensive set of tags, but stops short of modeling a specific type of XML document.

  For example, a "Book" tagset might comprise several modules that, taken as a collection, define a complete set XML tags for marking up a book or things related to a book. E.g., a book tagset might be comprised of these modules:

  • Special module for defining book metadata tags,

  • General module for defining tags related to text formatting,

  • General module for defining tags related to references,

  • Public model for defining tags related to tables,

  • etc.

• Schema: a specific use of a tagset to form a specific content model. This model would be coded as a DTD, an XML Schema (XSD file), etc. that in turn would reference specific modules from the tagset.

  For example, three different schemas could all be built from the single "Book" tagset:

  • A "book" schema that models an entire book from cover to cover;

  • A "chapter" schema that models just a book chapter;

  • A "book info" schema that models the information needed to create metadata feeds about a book.

Tagset/Schema "Customization Levels"

One could consider that the possible approaches to customizing a public tagset or schema could occur along a spectrum between two ends:

• On one end, no customizations are applied and the public tagset/schema is used precisely as-is.

• On the other end, only the general principles behind the public tagset are used to "inform" the design of one's own schema; the actual public tagset isn't used at all in the development of the target tagset or schema.

In reality, ACS' application of the NLM tagsets occur somewhere between these extremes. From our own anecdotal experience and discussions with other organizations, we suspect that many other applications of the NLM tagset also fall somewhere between these extremes.

We will give names to a few points along this spectrum; we will call these "customization levels."

List of "Customization Levels"

• As-is: The public version is used without changes or modification, with the sole exception that the schema filename or public identifier may be different.

• Extended: A superset of public tagset/schema is used, with additional tags defined beyond the public version. XML that is valid for the public schema would also be valid to the extended version of the schema, although the reverse may not be true.

  For example, the definition of tag <xyz> in the public schema may allow tags <a> and <b>, while the customized version defines tag <xyz> allowing tags <a>, <b>, and new tag <c>.

• Reduced: A subset of the public schema is used, with some tags removed from the schema. XML that is valid for the public schema may not be valid to the reduced version, although the reverse would be true.

  For example, the definition of tag <xyz> in the public schema may allow tags <a>, <b>, and new tag <c>, while the customized version defines tag <xyz> as only allowing tags <a> and <b>.

• Customized: Modifications are made to the public tag definitions that are a combination of both extensions and reductions. A “customized” tagset still uses the same tag names and similar tag hierarchies as in the public schema, but has changes that are a result of a combination of extension and reduction. XML that is valid for the public schema is likely not valid to the customized schema, and likewise XML that is valid to the customized schema is likely not valid to the public schema.

  For example, the definition of tag <xyz> in the public schema may only allow tags <a> and <b>, while the customized version defines tag <xyz> as allowing only tags <b> and <c>.

• Built from: Modifications made to the public tagset are more substantial and include renamed tags, non-trivial changes to the tag hierarchy, etc. Many of the modules from the public schema are used as the starting point for a tagset in this category.

  For example, the definition of tag <xyz> in the public schema may allow child tags <a> and <b>, while the customized version renames the tag as <abc> and only allows tags <a> and <b> to exist when grouped within tag <c>: <abc><c><a/><b/></c></abc>

• Informed by: The public tagset may be referenced during the design of the custom tagset, but is not directly used in its construction. Tags could occasionally share similar names or models, but they are not defined using the same modules.

<xyz>
   <a/> <b/> <c/>
</xyz>

<xyz>
   <a/> <b/> <c/>
</xyz>

<xyz>
   <a/> <b/> <c/>
</xyz>

<xyz>
   <a/> <b/> <c/> <d/>
</xyz>

<xyz>
   <a/> <b/> <c/>
</xyz>

<xyz>
   <a/> <b/> <c/>
</xyz>

<xyz>
   <a/> <b/> <c/>
</xyz>

<xyz>
   <a/> <b/> <c/> <d/>
</xyz>

<xyz>
   <a/> <b/> <c/>
</xyz>

<abc>
   <c>
      <a/> <b/>
   </c>
</abc>

<xyz>
   <a/> <b/> <c/>
</xyz>

<abc>
   <aa/> <bb/> <cc/>
</abc>

Tagset/Schema "Customization Implementation Methods"

In addition to defining various levels of customization, we further recognize two basic approaches to implementing these customizations (with the exception of the "as-is" and "informed by" levels):

• Modifications. A rather simple and straightforward approach is to merely edit the tag definitions within the actual modules provided with the public tagset. An advantage of this approach is that it can be done rapidly with little understanding of the underlying design of the public tagset.

  However, one drawback to this approach is that it may not be obvious to other future schema developers if a given module is the original version or a customized version. Another drawback is the need to carefully manage versions of a shared module. Otherwise, an application that has awareness of several different schemas, where those schemas "share" common modules (for example, a book and journal schema share a "paragraph" module), may pick up the wrong version of a module when attempting to load a given schema. This could lead to runtime errors or unintended consequences for applications like composition systems and XML editors that are often configured to handle different types of content.

• Overrides. With this approach, the public tagset files are not directly modified but are left intact. Any customized tag definitions are located within separate, schema-specific modules that are positioned within the schema to "override" the public versions of the same tag definition.

  An advantage to this approach is a shaper divide between customizations and original tagset definitions. The original module from the public tagset is not modified in this approach, so any other schemas that use the public module will continue to pick up the correct tag definitions.

  However, this approach does require that the original tagset was specifically developed to allow "override" capabilities. The NLM tagsets are fortunately and thoughtfully designed with many override capabilities.

Example. Consider that an organization wishes to leverage a public tagset to build a schema for their publication application. Within that public tagset, module tagsoup.ent contains tag definitions for two tags: <xyz> and <abc>. However, while the organization wants to use the existing public definition for tag <xyz>, they decide that they need a different, customized definition for tag <abc>, perhaps one that allows some additional child tags.

Assuming that the public tagset was designed to allow overrides, they have two choices on how to implement their customization for tag <abc>:

1. They edit module tagsoup.ent to change the original definition of tag <abc> to be their own definition.

2. They create a second, enhanced definition for <abc> within a new, private module called custom-tagsoup.ent. Both modules tagsoup.ent and custom-tagsoup.ent are used within their schema, but because custom-tagsoup.ent is referenced first within the schema, its custom definition for tag <abc> takes precedence.

Tagset/Schema “Customization Profile”

A “customization profile” for a tagset/schema can be defined using the combination of the "customization levels" and “implementation methods” defined above. A two-dimensional chart that contains the possible combinations can be formed using the customization levels on the X-axis and customization implementation methods on the Y-axis. Within this chart, the Y-axis implementation levels would not apply to the extremes of the X-axis customization spectrum: neither the "as-is" nor the "informed by" customization levels would actually utilize the customization implementation methods on this scale. (6)

Altered Basic High-Level Structure

Instead of using <article> as the root element, ACS opted for the more generic term of <document>.

The concept of "metadata" was already established internally, so this name took the place of NLM's <front> tag.

In addition to journal and document metadata sections, we had significant amounts of metadata related to the production process that we wished to keep within the document. A new <processing-meta> tag serves as a container for this type of information.

<article> 
  <front> 
     <journal-meta> 
    <article-meta> 
  <body> 
  <back>

<document> 
  <metadata> 
     <journal-meta> 
     <document-meta> 
     <processing-meta> 
  <body> 
  <back>

More Semantics Using ACS Terminology

ACS Pubs wanted to retain its existing production and product related terminology of "figure," "chart," and "scheme," so instead of using NLM's approach of one <fig> tag that can be further distinguished by using a @fig-type attribute, separate <fig>, <scheme>, and <chart> tags were defined. The differences go beyond mere naming however. For example, per ACS journal style, a <fig> is displayed with its label and caption underneath the image, while a <chart> is displayed with its label and title above the image.

Whereas the NLM tagset requires an <article-title> to be present if <title-group> is used, some types of ACS articles only have a need for a title for use on the web so a <web-title> tag was added. While the original ACS tagset lacked a "subtitle," later versions copied NLM's <subtitle> tag but renamed it as <document-subtitle> for consistency within ACS' tagset.

ACS also has long-standing production and product terms that differ from the NLM tagset: "SI" (supporting information) to refer to supplementary material outside of the article, and "WEO" (web enhanced object) to refer to online-only media components of an article, such as an animation.

More examples of ACS-specific terminology captured as additional tags are listed below.

ACS Citation Tags

ACS reference styles also differed from the out-of-box NLM citation models. ACS retained NLM's general-purpose <citation> tag (which was renamed to <mixed-citation> in NLM's v3.0 tagset) for use with non-journal citations, such as book and patent citations, that tended to have variability in the types of bibliographic information supplied and styling intended by the author. This model allows (and expects) that any required punctuation and spacing is included between the semantic child tags. The XML consumer, such as a page composition engine or an XML-to-HTML translator, has little to do when rendering these citations beyond perhaps applying some styling on some of the semantic tags (such as styling the contents of a <year> as bold).

For more highly-structured journal citations, NLM's v2.3 tagset defined a structured citation model, the <nlm-citation> tag, which reflected NLM's own citation style at the time. This tag allowed only certain child tags (like <source>, <year>, etc.) within a pre-defined order. (Since then, NLM's v3.0 tagset has deprecated the <nlm-citation> in favor of a somewhat different tag, the <element-citation> which allowed a larger set of child tags but no longer enforced a particular order.) For both <nlm-citation> and <element-citation> tags, any loose, untagged text was disallowed, with the expectation that punctuation and spacing between elements were to be generated by the XML consumer.

ACS has three primary journal reference styles that we felt would benefit from a highly-structured tagging design similar to NLM's <nlm-citation> and <element-citation> tags. Since ACS was not seeking to adopt NLM's actual citation style that was inherit in the <nlm-citation> tag at the time, we decided to define structured ciation models for each of our three ACS primary journal citation styles:

1. acs-titles: our standard citation style that included article titles,

2. acs-no-titles: an abbreviated form of our standard citation style that omitted titles,

3. acs-biochem: a separate citation style for our biochemistry titles.

An example of a tagged structured ACS citation follows below:

<acs-titles>
     <acs-cite-author>
          <surname>Bader</surname>
          <initials>M. W.</initials>
     </acs-cite-author>
     <acs-cite-author>
          <surname>Bardwell</surname>
          <initials>J. C. A.</initials>
     </acs-cite-author>
     <article-title>Catalysis of disulfide bond formation and isomerization in 
	     <genus-species>Escherichia coli</genus-species></article-title>
     <source>Adv. Prot. Chem.</source>
     <year>2002</year>
     <volume>59</volume>
     <fpage>283</fpage>
     <lpage>301</lpage>
 </acs-titles>

As suggested by this sample, the ACS citation models are similar to the <nlm-citation> and <element-citation> models: loose text is disallowed, and all semantically identifiable components of the citation are individually tagged within their respective tag. Any spacing and punctuation required between elements for display is generated by the XML consumer/renderer.

We saw several benefits to applying this structured, "data-oriented" approach to tagging journal references:

• Lower production costs because editorial staff did not have to spend time getting each punctuation and space edited just right (as they do for non-journal citations using the <citation model>); they just focus on the who's, what's, where's, and when's of a citation.

• More capabilities for future re-use; the citation information could be harvested and presented in different forms for future products.

• Higher accuracy of reference linking to CAS ChemPort, CrossRef, PubMed, etc.

ACS Product and Domain Specific Features

A few features that are specific to ACS Journals and their chemistry sciences content requires special tags in the ACS Journal Tagset. A special chemical notation occasionally used in some chemical expressions within text and titles, "tie-bars" resemble horizontal square brackets that hang above or below the line of text and "tie" two specific characters together. Since this notation may or may not occur within the XML document's natural hierarchal structure, it is implemented as milestone tags, with one tag indicating where the tie-bar should start and another tag indicating where it should end.

Due to ACS Pub's focus on material from chemistry-related disciplines, additional tags to identify chemical names and processes were defined in our tagset. Because some potentially hazardous steps within experimental procedures may need to be specially highlighted or extracted, a <caution> tag is also available.

Finally, one type of ACS product is termed as a "living review." In this product, a previously-published review article is selected to be republished (as a new article) with new or updated information added. Unique to this product is that the new information is visually distinguished from the original text, in both the paginated and HTML products, by using special styling such as the color red. In addition, a need to summarize changes between versions and to provide a special mechanism to identify the original article resulted in a few new tags added to our tagset.

ACS Table and Math Extensions

We defined a few extensions for our use of the public MathML2 and CALS Table modules. For MathML, we have a need to indicate specific alignment points. These are needed both within single equations that break across lines, and for aligning multiple labeled equations in relation to one another. The MathML2 specification had no direct support for this, so we extended our instance of the MathML2 sub-schema to allow an <ACS:marker> tag within the equation markup, allowing alignment point information to be supplied to the page composition process. Additionally, we defined tags to enable tie bars in math, similar to those added for text content.

One of the first modifications that we made to our original ACS Journal Doctype was extensions to the CALS table module within our tagset. Prior to XML, the Journal production team had a long-standing approach to handling tables by assigning different row types, which caused different behaviors within page composition. Another early extension was support for handling indentation behavior for column and individual cells.

Other non-compatible Changes

Some tags were seemingly carried over from the NLM Tagset to the to the ACS Tagset, but upon closer inspection, they behave very differently.

NLM Tagset Features Not Implemented in ACS Tagset

The ACS Journal Tagset did not implement many tags within the pubic NLM tagset because there was no product or process need to "clutter" our implementation with them. A few examples of these are listed below.

NLM Journal Tagset Extensions within the ACS Pubs' Delivery System

The NLM Tagset in use by ACS Pubs' delivery system originated by starting with the standard NLM tagset and making customizations to provide additional functionality and capabilities as required by the core delivery system. Because these customizations were implemented without breaking compatibility with XML content that is compliant with public "native" NLM tagset, and was implemented by a combination of both overridding and directly modifying the tag definitions within the original public modules, we characterize these extensions within the Customization Profile at the "Extended" level and using a "Mixed" implementation method.

Due to the fact that the ACS Pubs' production journal schema and delivery platform schema are both based on the same root NLM tagset, one might reach a conclusion that journal production XML content could be readily absorbed by the delivery platform. In reality, this is only partially true. As pointed out in the prior section, the ACS Journal Tagset and Schema have non-trivial differences from the public NLM tagset, differences that are even more apparent when comparing to the customized version of the NLM tagset used by our delivery platform. ACS production XML is not functionality equal to the NLM XML required by our delivery system, so a conversion step was needed.

ACS Production to Literatum Journal Content Interface

We will briefly cover the overall process by which ACS journal XML content is converted and delivered to ACS Pubs' delivery platform. Not only is a translation required to mechanically convert ACS markup to equivalent NLM markup, the converted XML must additionally conform to the tagging conventions specifically required by ACS Pubs' delivery platform. Merely ensuring that the resulting XML document is "valid" against the delivery system's NLM schema is not sufficient to ensure that all system-required tagging constraints are met.

Considering that this translation needs to occur as content is passed from the production system to the delivery system, an obvious question may be "in which system should this translation take place?" Should it be an export function from the journal production process? Or, should it be an import function within the delivery system? Our answer is "both."

Because Atypon has intimate knowledge of ACS Pubs' Literatum-based delivery system, and thus knows precisely what is required of the resultant NLM XML, a part of Atypon's original Literatum implementation engagement with ACS Pubs included writing an "ACS2NLM" lexer to convert ACS production journal XML into a form of NLM XML that is compliant with ACS Pubs delivery system. An advantage of having this "import" lexer within the delivery system is that it isolates ACS Pubs production staff from needing to have specialized knowledge or training of the precise tagging needed to drive the inner workings of the Literatum system. This approach does have its costs as well: when ACS Pubs plans product or process changes that would manifest as changes in the ACS XML, we must factor in additional overhead for specifying, developing, deploying, and carefully regression testing any required changes of the "ACS2NLM" lexer.

On the side of the journal production workflow system, we developed a "content delivery normalization" export function that is applied to an instance of the ACS XML as it is being packaged for online delivery. Because ACS journal XML often contains non-trivial tagging variances between journals (to meet journal-specific needs of the paginated print/PDF products within production), these “content delivery normalization” edits within the production workflow system reduce the tagging permutations that would otherwise need to be handled by the delivery system's "ACS2NLM" lexer, thus preventing needless complexity within that translation process. This content normalization is applied only to a copy of the XML that is being packaged for delivery, and the original ACS XML containing the full set of product-specific tagging remains unaltered and safely stored away within the production CMS.

Addition of XInclude

In Atypon's model, a book XML contains book-level information (title, editors, ISBN, publication and copyright information, etc.) as well as a list of chapters listed by DOI number. The chapter XML files share the same schema as the book XML, and also use <book> as their root element.

In contrast, our use of the automated page composition solution (built on PTC's Arbortext Advanced Publishing Engine) required a more explicit method for linking chapter XML into a book XML when composing a full book. For this purpose, we implemented support for the XInclude (8) within the ACS Book tagset. The Xinclude linking mechanism allows production staff to work with the entire book – including all content from individual chapter XML files – as a single composite document.

We have found the use of XInclude to be a very natural, successful, and beneficial extension to the Book tagset, and would urge the NLM Tagset owners to consider inclusion of XInclude in a future version of the public NLM Book tagset.

Use of OASIS Table Model

The public NLM Book tagset uses the XHTML Table model, although modules are included to enable the OASIS table model. Within Atypon's customized version of the Book tagset, both XHTML and OASIS table models are enabled, although the OASIS table tag names all contain an "oasis:" pseudo-namespace prefix to prevent tag clashes with XHTML tag counterparts. In the ACS version of the Book tagset, we dropped the XHTML table model, and dropped the "oasis:" pseudo-namespace prefixes from the OASIS table tag names. We made this change for three reasons:

1. Our XML editing and page composition platforms worked with OASIS tables much better without the "oasis:" pseudo-namespace prefix.

2. The OASIS model allowed greater control and flexibility in meeting ACS book product requirements as compared to the XHTML model.

3. Production staff already had experience and training in using the OASIS table model from our journal tagset.

Addition of DocBook <index> Model (Atypon)

One notable gap from the public NLM Book tagset is the lack of dedicated tags to facilitate the creation of an index. ACS Symposium Series Books feature a subject index in the back of each book containing index entries that list the page numbers for pertinent terms, figures, and tables. The Atypon version of the NLM Book tagset contains integrated support for a simplified version of DocBook's tag model, and we found this tagging met our needs for generating the subject index section for each book.

Addition of <book-series-meta> (Atypon)

Another gap from the public NLM Book tagset was support for identifying a series to which a book belongs. For ACS Pubs, the Symposium Series to which the books belong is a distinct publishing identity, much like a journal. Similar to a journal (and the <journal-meta> information that accompanies most journal articles), a book series has a set of metadata attached to it, such as an ISSN. We found that Atypon's implementation of the <book-series-meta> fit ACS Pubs' needs perfectly.

Digital Assets

Within C&EN magazine production, there is less of a need to semantically identify the type of non-narrative content such as tables, images, media, etc. as compared to journals and books. Some non-narrative content can fall into more than one of these content type classifications. As a result, C&EN collectively refers to these non-narrative content types as "digital assets."

Within C&EN's tagset, we removed the existing tags for tables, figures, graphics, equations, etc. In their place, we defined a single "digital asset" tag that allows multiple types of content. Some digital assets can have more than one content type, such as a table that provides table markup to drive HTML, an image for the printed page, and a spreadsheet file for further use by the online reader.

Content modularity

Because magazine content often has a looser concept of article boundaries and a more flexible content structure (see our earlier introduction to the C&EN Magazine product), we introduced XInclude to allow more modularity of how individual components are produced and assembled for publication. While the Books production schema introduced XInclude at one level (i.e., from the book to its constituent chapter and index content sections), our magazine tagset implements xinclude to allow the following modularity:

• Articles can contain other articles. This is implemented as a recursive "<article> allows <article>" definition, allowing for any type of sub-article arrangement required by magazine production.

• Any type of digital asset (table, image, media file, etc.) and its related metadata can be linked to an article or sub-article. This is different from merely using an @href attribute to reference a given content file: a separate XML file for the digital asset containing the object's title, caption, credits, etc. encapsulates all information about the digital asset. This digital asset XML file also includes the digital asset's specific content tagging (in the case of tables) and/or reference(s) to the external constituent media file(s).

Pagination

The nature of C&EN's print issues, like many magazines, do not always have a strict sequential pagination of their articles, requiring a flexible approach to capturing page numbers. The page number tagging model was expanded to allow for ganged (one article starts on the same page that another article ends), continued, and sub-article issue layouts.

Ads

The financial model of most magazines usually includes at least some level of advertising content. Tagset features were added to facilitate the capture and management of ads. The model for an ad is based in part on a simplified form of a sub-article model with some additional ad-specific metadata tags defined.

Magazine specific features

Some other specific content features are regularly used by C&EN magazine content, requiring specialized tags to capture them. A few of these are listed by way of illustration:

1. dek: similar to a subtitle or synopsis, a dek is a short caption of the article displayed above or below the title of an article or digital asset with the intent to draw the reader's interest. See the figure of a magazine page below for examples.

2. eyebrow: C&EN uses the term "eyebrow" to capture a word or short phrase to give a snapshot context of the article to the reader. See the figure of a magazine page below for an example.

3. pull quotes: used widely by all types of news and magazine publications, a pull-quote is a short passage extracted and highlighted from the article's narrative with the intent to capture the reader's interest. The passage may be extracted verbatim or it may be edited or paraphrased. See the figure illustrating a pull quote below.

Fig. 3

C&EN Magazine Page Example. A page from C&EN showing various content features.

Fig. 4

Pull Quote Example. A pull-quote can occur anywhere in text.

Flexible Content Categorization Model

One requirement is to allow multiple types and multiple layers of categorization to be applied to any given article. The print issue's table of contents represents one type of categorization, e.g., grouping "business" related content under one section while "technology" related articles are listed within another section. RSS and syndication feeds are often organized by topic, such as "green chemistry" or "CO₂." Some news stories may be related to a recently published ACS Journal article, leading to a desire to associate the magazine story with a particular ACS journal. The approach that we ended up with was a categorization structure using a recursive model, allowing any number of category types and values to be assigned. The tag model was defined to allow many types of metadata regarding a given category: its type, its "display names" as intended for presentation, an internal or "code" value, its source system or taxonomy, etc.

Busting the NLM DTD "compatibility" myth

We found a common misconception, both within our organization and within the larger STM publishing community: that XML is either compatible with the NLM DTD or it is not. Instead, as we have tried to illustrate here, reality is more flexible: there are multiple levels of customization and compatibility that are possible. Because the NLM DTD cannot be all things to all organizations and their respective products and processes, customization should be expected.

Additionally, there is no "standard" way to tag an "NLM XML" content file. Due to the inherit model flexibility within the NLM tagsets, we find that organizations or systems that leverage the public NLM tagsets will often, out of necessity, enforce additional specific product, process, or system tagging requirements that go beyond the rules encoded within NLM's schema. The "NLM XML" produced by one organization or system may fail to meet the tagging conventions required by another organization or system – without some type of translation process between them.

The view that the Journal Archiving and Interchange tagset provides the basics for encoding STM content seems most appropriate to us. It promotes effective exchange of information between organizations while still being designed to allow many different styles of tagging.

Moving from monolithic one-size-fits-all schemas vs. specialized schemas

As we described in the section titled "Journals: ACS Pubs' Use of NLM Journals Tagset," we originally had a single DTD to handle production, print composition, web delivery, content interchange with external parties, and content archival. Not only did we struggle with implementing support for increasingly widely varied and sometimes conflicting requirements, but the logistics of testing, coordinating, and distributing updates to all parties and systems also grew increasingly challenging.

From this experience, we offer this advice: watch for warning signs that you are over-extending your tagset/schema. One shared tagset can be designed with shared modules to support multiple application- or system-specific schemas that want to share a common vocabulary. This allows specific schemas to evolve without needlessly impacting other processes. As an example, our implementation of three "flavors" of our most recent v1.03 Journal schema ("External," "Production," and "Layout") follows this approach. It should be noted that development of translation steps (e.g., XSLT scripts) is needed with this approach to transform XML content from one schema to another.

Use of XInclude for Books & Magazine

The addition of the XInclude to our Book and Magazine tagsets has proved to be a very positive and useful enhancement for ACS Pubs. Allowing the same content to be processed as either smaller stand-alone chunks or within context of larger composite documents, without the need for intervening translations, has provided tangible benefits and flexibility to both our staff and our XML applications.

Three-part packaging to defining XML tagging requirements

We have found that specifying tagging requirements by using only a DTD is insufficient. Instead, using a package consisting of three interdependent deliverables provides the highest level of success:

1. The schema (a.k.a. DTD) itself.

2. Documented tagging conventions, with validation tools & services as needed to enforce the conventions.

3. Complete XML samples that are valid to both the schema and the documented tagging conventions.

Providing just the schema or DTD itself to another group or organization, with no additional guidelines, provides an incomplete picture regarding how to create or use the required tagging. Documented tagging conventions will articulate how to supply or interpret tagging that will meet product or process related requirements. Also, because written documentation can be incomplete or misinterpreted despite the best efforts of the author(s), sample XML files can help fill in any gaps in comprehending the requirements.

In addition to more clearly specifying our tagging to external consumers, we also found benefits internally during the development process. The mere process of creating all three deliverables actually reinforced a comprehensive specification of our tagging. The process of creating the "convention documentation" often reveals gaps within the schema that need to be further refined, while the process of creating XML samples often revealed gaps in the tagging conventions.

When we are asked for "a copy of our DTD," we do not supply just the DTD itself because this only tells part of the story; we supply the complete package of DTD, conventions, and samples. As a rule, we consider that development of an XML schema is not complete until the conventions and samples are also finalized.

"XML as a product" mentality

One significant value of an XML-based content production process is the ability to reuse content for future products or applications. To fully enable this, however, requires a mindset that considers the XML content itself as an internal product in its own right. Without reinforcing this philosophy an XML application can devolve into mere inter-process content glue, meeting only the needs of the immediate systems and processes with little regard to how the XML content could be constructed for higher degrees of reuse.

Within a busy production environment, where the primary staff focus can be to "just get it published," we found that staff occasionally took shortcuts by setting up informal tagging conventions to accomodate new product features. These informal tagging conventions sometimes caused problems further downstream within our web delivery platform or prevented us from cleanly re-using the content for other purposes. We addressed this within the Journal and Book production groups by forming a "Tag Team" that is charged with both establishing XML tagging conventions and participating in the new product development process to ensure that any new tagging requirements are carefully evaluated with all current and future XML uses in mind.

ACS Pubs' "Validations service" for Journals

In addition to the ACS Journal production DTD, some of the additional tagging conventions that we defined are critical for successful operation of our production systems. For these critical conventions, we developed a "validations service" that is used throughout the production workflow. Some of these business rules, such as ensuring that the tagged volume and issue numbers are valid for the tagged journal ID, are requirements that a DTD could not enforce. In addition, some validations enforce more basic tagging conventions, such as ensuring the number of table cells in a row match the number of table columns; again, this is not something that the DTD alone could enforce.

We had evaluated several public validation standards and frameworks, most notably Schematron, but none offered one thing that we needed: validation of the XML using external data sources, such as production schedule information defined within our workflow system. As a result, we built our own validation framework, using Groovy (9). This framework allows full programmatic expression of individual validations and use of existing Java application classes within our production workflow system. The validation system is hosted as a web service, allowing it to be called from many different XML processing clients: ACS staff working within Arbortext Editor, our XML conversion and composition vendors (before they return an XML file back to us), and the production workflow system itself at various checkpoints. It has been in production use by ACS Pubs with minor updates since 2007.