XML and Ejournals:  The State of Play
Judith Wusteman

AUTHOR
Dr Judith Wusteman is based at the Department of Library and Information Studies at University College Dublin, Ireland.
judith.wusteman@ucd.ie
http://www.ucd.ie/~lis/wusteman/index.html    

Professional bibliography
Judith Wusteman joined the staff of the Department of Library and Information Studies at University College Dublin in September 1997. Prior to this, she spent seven years as a lecturer in computer science at the University of Kent at Canterbury. Her research interests are in electronic publishing and humanities computing, specifically e-journals, document structure and text encoding (SGML and XML). She has been involved in various electronic library projects and has provided SGML and XML consultancy for ejournal, encyclopaedia and digital library systems.

Keywords
Journals, XML, SGML, publishers, aggregators 

ABSTRACT
Within the library world, there is a growing interest in the use of XML in journals, not least because of its implications for ejournal archiving. But what is actually happening in the commercial journals market? How far have XML and its related standards permeated the production of real commercial journals and how do publishers and other providers of journals see this area developing? This paper looks at the activities and future plans of a selection of publishers and aggregators in the STM journals market, although many of the comments relate to the entire journals arena.

INTRODUCTION
Until quite recently, the use of the markup language systems SGML and XML in the journals production process was only of interest to a few "techies" in publisher production departments. The topic did not greatly impinge on most librarians; apart from a few experiments, the use of "neutrally-encoded text" was a purely internal affair for publishers. There wasn't much evidence of SGML or XML in the bibliographic information received by libraries. And it is still true that, by the time users access ejournal articles, they are generally displayed in PDF or HTML. But the implications of XML for metadata are now being widely discussed and proposals for the use of XML for ejournal archiving are emerging. The application of XML to ejournals is now a hot topic. 
This article looks at the state of play of XML in the journals industry; how XML and its related standards are permeating the production of journals and how publishers and other journal providers see this area developing. It concentrates on the perceptions and plans of a selection of publishers in the STM ejournals market, though many of the comments relate to all disciplines and to journals in paper as well as electronic form.

BACKGROUND
SGML has been used in the development of journals, and latterly ejournals, since the SGML standard was defined in 1986 (Cave,1998a). In the pre-ejournals era, SGML journal DTDs, or Document Type Definitions,  were used mainly within individual publishing companies for the internal representation, processing and storage of article and journal-level metadata, and sometimes abstracts. When the major aggregators such as Swets and Blackwells (now merged [1]), EBSCO [2] and Dawson (now part of Divine [3]) moved from managing paper journals to ejournals, the role of these publisher DTDs was expanded to include information interchange between the publishers, aggregators and, subsequently, libraries. By the time the XML family of standards started to be developed in 1996, SGML was a well-established, though not universal, method for transmission of such information. In addition, SGML was increasingly being used to store the full journal article text. In a few experimental cases, this full text SGML was actually being displayed to the end-user, as with the OCLC Guidon system (Hickey, 1994).
But SGML was limited by the fact that it wasn't designed for the Web and hence did not have the popular appeal of its offspring HTML; there was always a lack of browsers and reasonably priced software. This and the time-consuming nature of marking up text made SGML a huge investment for publishers, though one that many were prepared to make. It is open to argument whether, if XML hadn't appeared, the journal industry would have got fully behind SGML. But now that XML has appeared, it is almost certain that the latter will have a permanent and increasingly important role in journal production, delivery and archiving.

THE PLAYERS  
Who are the players in the production and delivery of ejournals? Between authors at one end and users at the other, the ejournal article may move between publisher, editor, reviewers, production company, aggregator and library. Depending on the particular journal, the article may spend some time with an external copy editor and may visit its original author a few more times. If a paper copy of the journal is to be produced, versions of the article may end up with typesetters and printers. The flow of information in this process is summarised in Figure 1 (END OF ARTICLE).

Some publishers provide end-user access directly to their own ejournals. Elsevier Science Direct [4] and Wiley InterScience [5] systems are examples. The same publishers and others are likely to submit their article metadata, abstracts and increasingly the articles themselves to abstracting agencies, and to some of the many aggregators such as Swets Blackwell, EBSCO, ingenta [6] and OCLC [7]. In some cases, individual publishers act as aggregators for other smaller publishers. The American Institute of Physics (AIP) [8], for example, hosts journals for several smaller organisations (Huber, 2000). Publishers may employ production companies to convert journal material into the electronic formats required by the other players in this web of dissemination.  Each of the players in this process has its own particular approach to the use of XML or SGML. Those that are using either of these markup language systems are at different stages of incorporating them in the workflow, as discussed later.  

STANDARDS  
	When SGML first came to prominence in journal publishing, it was widely assumed that it would be possible to develop and use one standard DTD, or set of DTDs, to define the components of journals. The ISO 12083 DTDs of 1994 [9] were an attempt at such a standard. They covered markup of journal and article metadata, abstracts and article content, including mathematics. Other "standard" journal DTDs to emerge included the  MAJOUR (Modular Application for JOURnals) DTD [10] in 1991 and later SSSH (Simplified SGML for Serial Headers) in 1996 and SSSH2 in 1998 [11]. MAJOUR and SSSH were designed by publishers primarily as exchange formats for bibliographic information for scientific articles (Cave, 1998a; Wusteman, 1997).
But it soon became obvious that publishers were not prepared to conform to one standard or even several. Many publishers developed their own proprietary DTDs using ISO 12083 or MAJOUR as a base, but few used these standards without customisation. It is interesting to note that the header in the Elsevier Science Article DTD bears little resemblance to the MAJOUR DTD, despite Elsevier being a major player in the latter's development (Cave, 1998b). The ISO standard came in for particular criticism; it was claimed that it suffered from being presented as a fait accompli rather than being allowed to evolve and hence reflect real user requirements. It is "too generalised... designed to work for everyone but it doesn't really work for anyone" (Rosenblum & Golfman, 2001 p.11). However, it has its supporters; AIP uses a customised form of the standard and intends to use a customised form of the 12083 XML DTD (McMahon, C. 2002, personal communication, 11 December).
Modified versions of MAJOUR and ISO 12083 can still be detected in many publisher-specific DTDs such as the MAJOUR-based Springer Verlag DTD [12]. Many of these DTDs have been tweaked for years. Any idea of being based on a standard has been lost but the lessons learnt from this customisation process are now influencing the structure of the new slowly-emerging generation of XML DTDs. 
Contrary to expectations, and despite reflecting publisher requirements, SSSH did not catch on. It was used in the SuperJournal [13] and Infobike [14] projects and is still accepted by some journal systems such as OCLC's Electronic Collections Online but it does not appear to be being advanced; the fact that no XML version is in the pipeline is ominous for this standard's survival. 

THE NEW "STANDARDS"
A new collection of quasi-standard DTDs have been emerging for some time. Often developed for one specific publisher or system, they are being "borrowed" by other publishers or systems. The Elsevier SGML DTD [15] has been, in effect, a proprietary standard for years; the Highwire, PubMed Central and Wiley DTDs are all based on various versions of this Elsevier DTD (Rosenblum & Golfman, 2001). The PubMed DTD [16], one of the few to have already adopted XML, may become another de facto standard. It is supported by OCLC, along with DTDs such as SSSH2 and Elsevier and "in many cases, the publishers proprietary DTD" (Schweitzer, J. 2001, personal communication, 1 November).
The feasibility of archiving ejournals is a hot topic at present (Smith, 2001; Rosenblum & Golfman, 2001) and has resulted in further external scrutiny of individual publishers' DTDs. If a widely accepted standard DTD had emerged in the journals field, archiving ejournals would have been a simpler process. As it is, the investigation must concentrate on the feasibility of converting XML and SGML material marked up using a whole range of DTDs into a format that uses a single archival DTD. The feasibility study for the Harvard University Library E-Journal Archiving Project comments ruefully that "multiple proprietary DTDs create a Tower of Babel rather than a consistently accessible repository" (Rosenblum & Golfman, 2001 p.4). 
But the attempt to encourage true international standards never went away and may gain strength from experience of actual use within the publishing community. Peter Murray-Rust and Henry Rzepa (2002), developers of the first XML application in any domain, CML (Chemical Markup Language), comment "We believe that the use of markup languages will be dynamic and evolve as they fill needs and can be implemented". Their own publishing language, STMML (Scientific, Technical and Medical Markup Language),  is just one of several proposed standards in this area, as is the proprietary eFirst XML system [17].
Another development born from experience appears to be the recognition that a single DTD may not be appropriate throughout the entire journal production and delivery process. UK Royal Society of Chemistry (RSC) experiments into the incorporation of XML-based molecular information in journal articles concluded that "document design requirements of DTDs for authoring and production were quite different" (Kidd & Harlow, 2001). As Elsevier migrates to XML, two DTDs have been created: one for input from suppliers and one for Web delivery (Schrauwen, R., personal communication, 5 March 2002). The use of multiple DTDs within a workflow is a common concept in other domains and may well be adopted in the journals industry.

AGGREGATOR REQUIREMENTS
Until recently, many aggregators required conformance of at least metadata to a prescribed DTD. This was either a "standard" or their own proprietary DTD. There was an early attempt by SwetsNet, for example, to enforce supplier conformance to a standard SwetsNet header DTD. But aggregators have found that they need to be more flexible in their demands. Some now request adherence to one of a set of DTDs or increasingly often to any DTD, a few "standards" suggested as preferable. The requirements of four sample aggregators are detailed below.

PubMed Central
PubMed Central (PMC) is unusual in requiring participating publishers to supply not just metadata but full article text in SGML or XML. However, it is flexible in accepting "any established DTD for journal articles" [16]. As already mentioned, there is also a PMC full text XML DTD derived indirectly from the Elsevier DTD, but there is no compulsion on publishers to use it.

Highwire Press
Highwire Press has adopted a modified version of the SGML Elsevier Science DTD 4.1.0 (Rosenblum & Golfman, 2001). This, in turn, has been adopted by some of Highwire's publishers. The British Medical Journal (BMJ), for example, used this DTD. Its own XML DTD, however, was subsequently developed in-house (Hearn, P., personal communication, 4 March 2002), an illustration of how quasi-standards are often used only as a starting point until in-house expertise has developed.
As John Sack (personal communication, 6 November 2001) points out, Highwire is not a traditional aggregator because it takes "no commercial interest in the intellectual property of the publishers [it] serves". Rather, it regards itself as a "service bureau" and its approach to the use of XML is driven by this. It works with whatever it is sent by publishers, be it SGML, XML, Word, PDF or even typesetting files. In this sense, its approach is more similar to that of ingenta than PMC. 

Ingenta
As explained by Dr Pete Trevellick ( personal communication, 11 October 2001), "the CatchWord part of Ingenta's business is primarily focussed on avoiding the cost of SGML or XML supply". It generates SGML headers and a binary page-representation from the typesetter's PostScript. This binary format can be converted by a Web server to various delivery formats, such as HTML, PDF or CatchWord's own format RealPage, as required. Catchword states that it does not envisage moving to full text SGML or XML tagging; it "works primarily to future-proof the delivery of the page appearance". But this future-proofing requirement could be met by the use of XML combined with XSL:FO style sheets.  
Small publishers, for example many learned societies, may own only a handful of journals, sometimes only one. Requiring no markup of such publishers is commercially necessary, particularly for those publishers who do not do their own composition work in-house. As Bide (2000) points out, it is likely that most publishers will continue to outsource technical production and content management. There is even a possibility, in Bide's opinion, that larger publishers may return to outsourcing rather than "continue development of ever greater technical resources in-house". But wherever this processing takes place, the introduction of XML early on in the ejournal production cycle makes sense and should be encouraged. 
 
OCLC ECO
As already mentioned, OCLC's Electronic Collections Online system accepts header information marked up using one of several DTDs such as SSSH2, PMC, Elsevier and, in many cases, the publishers proprietary DTD.  It has also created its own DTD "for publishers that are just getting started with electronic publishing" (Schweitzer, J., personal communication, 1 November 2001). As with Highwire, this "standard" DTD is often regarded as a useful stop-gap until publishers develop a DTD more specific to their requirements. So much for a single, long-term standard! 

SGML LIVES ON
Sacks is not alone in his view that there will be a "gradual shift to XML, especially for large publishers and those smaller publishers that do their own 'composition' work in house" (personal communication, 6 November 2001). But it would be misleading to imply that SGML was dead in journal publishing. For some publishers, the perceived advantage of XML is not yet sufficiently great. Indeed, several publishers already using SGML have recently produced new SGML DTDS. For example, in the last two years, OUP has developed a full text SGML DTD for humanities and social science ejournals (Drage, A., personal communication, 13 August 2001). But the momentum behind XML is certainly increasing. In Summer 2001, CUP was "testing the provision of full text SGML" and did not see any clear benefits in introducing XML into the article creation workflow (Fell, C., personal communication, 22 August 2001). By March 2002, CUP had begun to "implement an XML based workflow across [its] production operations" for both books and journals (Fell, C., personal communication, 11 March 2002). As pointed out by Sacks (personal communication, 6 November 2001), "the journals that are produced by professional printers/compositors will remain SGML-based for a long time." Having said that, when a highly regarded SGML/XML guru like James Clark proclaims that SGML compatibility, one of the central features in XML's design, is now much less important, and that: "With the aim of cleaning up the foundation of XML, we 'should be free to stab the SGML community, what's left of it, in the back' " (Dumbill, 2001), the conclusion must be that migration to XML may be advantageous. 

Introducing XML into the workflow
Many SGML-based publishers have already begun the migration to XML; the RSC [18] and the Blackwell Publishing Group (BPG) [19] were two of the first publishers to complete the move and to be using an XML DTD. Springer Verlag’s new full text XML DTD has been in use since October 2002. (Thibor, P., personal communication, 5 December 2002). Within Springer, it will replace the current MAJOUR-based SGML DTD; MAJOUR will continue to be supported for import and export of metadata (Thibor, P., personal communication, 1 March 2002). Similarly, Elsevier's article DTD has been converted to XML with its latest version, v5.0.0; Elsevier sees this as a first step to moving entirely from SGML to XML (Schrauwen, R., personal communication, 10 August 2001). 
The Institute of Physics Publishing (IoPP) is an example of a publisher that missed the SGML phase and moved directly to XML (Cox, T., personal communication, 10 December 2002). It serves a highly computer-literate community of readers and authors, and, until recently, LaTeX had been its basic production format. Its first foray into the use of XML was the conversion of headers and references from LaTeX to XML. In 2001, IoPP started its migration to full text XML. Authors are encouraged to submit Word or LaTeX files but PDF files can be submitted initially for use in refereeing. The Word or LaTeX is edited and converted to XML prior to the generation of PDF proofs. After correction of proofs and updating of the XML, the following outputs are produced: high resolution PDF for print; lower resolution PDF and HTML for electronic delivery and reference lists for linking. The proposed "XML workflow system in Journals production" will, Cox believes, result in a "better long term archive of journal data", production efficiencies and will add value and flexibility to IoPP content. 
SGML encoding was often introduced near or at the very end of the journal production process. It is still not uncommon for SGML and now XML headers to be generated from the typesetters' PostScript. Some of the more forward-looking publishers aimed to introduce SGML earlier in the cycle. How realistic it would have been for SGML to be used throughout the process, from initial authoring of articles to final display and archive is open to argument, particularly in view of the expense and complexity of SGML tools. XML standards and related software still have a long way to go but there is the possibility, at least, of an all-XML production, dissemination, display and archiving cycle. In this scenario, authors submit their articles in XML, they are reviewed and edited in XML, copy-edited and sent to typesetters in XML and disseminated electronically in XML – or via on-the-fly conversion to HTML until XML-savvy browsers predominate. 
This concept of a coherent XML workflow, rather than an inelegant conversion to SGML in the last minutes of production, is identified by several publishers as one of the aims of their SGML to XML migration. AIP, for example, has been "re-engineering [its] production workflow methodology to be XML-centric". In the current process,  conversion to SGML occurs "at the tail-end of the process"; the new system will create or convert to XML "at the beginning of the process" (McMahon, C., personal communication, 12 December 2002).
In Summer 2001, BMJ started to introduce XML into the workflow "by placing tools to convert from styled Word documents to XML close to the editorial desk" (Hearn, P., personal communication, 4 March 2002). The workflow is now fully XML-based. (Hearn, P., personal communication, 6 December 2002).
For most publishers, the introduction of XML in the journal lifecycle will be a gradual process. It may be first introduced at a fairly late stage in journal production, for example at typesetting, and then, with time, be moved back slowly through the production process. Before a completely XML-based workflow can be attained, there are many issues to be addressed; as Smith (2001) points out "authors don't want to actually spend any more time preparing materials to conform to rigid rules!" 

XML "Compliance"
As a first step in the migration of HTML Web sites from SGML to XML, for example HTML 4.01, to XHTML,  many Web authors are attempting to make their HTML files more XML compliant. This may be no more difficult than adding some missing close tags, particularly </p> and </li>, and putting quote marks around attribute values (for example, <img src="pic.gif">). Even the syntax difference for empty tags is easily dealt with: most later browsers will recognise <br  /> as well as <br>, although the former is not valid HTML 4.01. And there is freely available software, for example HTML Tidy [20], to do all this automatically.
A parallel process is happening in journal production. As an intermediary step on the way to XML, many publishers and other owners of journal DTDs are attempting to transform their SGML document instances into "XML-compliant" documents. What publishers mean by compliance varies from publisher to publisher. Some mean complete conformance to an XML DTD, that is, the production of valid XML files. Others are simply referring to the production of well-formed XML files, that is files that obey XML tag rules such as no tag omission and so on, but do not refer to an XML DTD. In many cases, these files are still valid SGML and are created using the original SGML DTD and SGML software, a useful "half-way house" (Cole et al., 2001) on the way to valid XML.
Some publishers refer to their content as "very close" (Schrauwen, R., personal communication 10 August 2001) to XML compliance or "compliant ...at the click of a button" (Morgan, C., personal communication, 3 August 2001). By this they generally mean almost well-formed SGML files that can be easily converted to XML. Wiley's SGML ejournal files, for example, do not use tag minimisation. Such minimisation, that is leaving out open or close tags which could be logically inferred from the context, is common in SGML documents as a method of cutting markup costs, but is now less necessary as WYSIWYG markup tools take over from manual markup. This is not to imply that marking up is now an inexpensive activity; it has been estimated that tagging articles with even minimal metadata "can add as much as 40% to costs" (Nature, 2001). 

Conversion of SGML DTDs to XML
As already mentioned, some journal DTD owners have reached the stage of converting their SGML DTDs to XML. Many SGML features are not permitted by XML; the following omissions have proved of particular relevance to journal DTD conversions (Apps & MacIntyre, 2000; Cole et al, 2001):
Inclusions which allow an element to appear anywhere in the content of an element or any of its subelements, despite not being allowed to do so by the applicable content model. For example, the ISO 12083 SGML DTD uses inclusions to allow floating elements, such as footnotes, to appear anywhere within an article.
Exclusions which prevent an element appearing anywhere in the content of an element or any of its subelements, despite being allowed to do so by the applicable content model. For example, the ISO 12083 DTD uses exclusions to prevent floating elements such as footnotes appearing within footnotes. (Rob Schrauwen of Elsevier (personal communication, 10 August 2001) "regrets very much" that exclusions are not possible; he feels they would help to make the Elsevier XML DTD more restrictive.)
"&" connectors which allow all elements in a content model to occur, but in any order. For example [21], the following SGML fragment from the BPG DTD version 3 allows surname (snm) to be mandatory and appear at any point within the author (au) element:

<!ELEMENT au  - - (title? & fnms? & snmprefx? & snm & degs? & ped? & roles? & linkr*)>
   
Complex mixed content models in which text and subelements are mixed. The XML DTD does not allow mixed content models to constrain the order or number of occurrences of individual elements (Cole et al., 2001). As Cole et al. explain, the following SGML content model would not be allowed in an XML DTD:

 <!ELEMENT Other ((author, journal) | (#PCDATA))>

Depending whether the SGML DTD includes many of the features detailed above, the process of conversion to XML has been found more or less difficult. The Elsevier SGML DTD, for example, was close to XML already. The only issues that needed to be faced were the existence in the SGML DTD of "a few mixed-content elements, one "&", an inclusion and an exclusion" (Schrauwen, R. personal communication, 10 August 2001). Similarly, the Ovid DTD required "very minimal alteration....No end-product functionality was lost" (Wittorf, B., personal communication, 5 March 2002). And again, the conversion of Manchester University Press's DTD was a "fairly trivial task"  (Apps, A., personal communication, 24 August 2001).
However, as Cole et al (2001) point out, it can be difficult to make XML DTDs as "restrictive and precise" as SGML DTDs. BPG found that the definition of some content models had to be relaxed to ensure XML-compliance [21]. For example, the au element in the SGML DTD was renamed name and rewritten in the subsequent XML DTD as follows: 

<!ELEMENT name (nametitle | forenames | surnameprefix | surname | qualifications | pedigree | roles | link | x | br)+>

As can be seen, the subelements of name may each appear any number of times and in any order, the only stipulation being that there must be at least one subelement within name. The requirement, present in the SGML version, that any element must occur once and only once, has been dropped; to define it would have resulted in a ridiculously complex content model. In such cases, explains the Blackwells DTD documentation, it is important to "understand that what's actually required for DTD 4-compliancy might be stricter than the content model appears". In other words, conformance to the DTD may not be sufficient to ensure correct content. At first glance, this might appear discouraging to those publishers considering conversion to XML. 
 In fairness to XML, it should be pointed out that even many SGML systems do not rely on the DTD to perform all checking of content. Elsevier for example, has used a "one-size-fits-all" SGML DTD (Pepping, 2001) that "supports a wide variety of publication item types" and then provides extra rules in the documentation as well as a quality control tool that is distributed to all SGML suppliers (Rosenblum & Golfman, 2001, p. 60). 
It should also be pointed out that, although more complex content models are possible in SGML DTDs, compromises that improve readability of journal DTDs sometimes mean that the full power of SGML is not used anyway. For example, in creating a header DTD for the eLib project Infobike, a forerunner of the commercial ingenta system, we wanted to include a content model for Publication information (pubinfo) that ensured that one of volume id (vid), issue id (iid) and cover date (cd) must be present. But we also wanted to allow either of the other two identifiers, or all three to be present – but only once. It is possible to describe this in SGML:

<!ELEMENT pubinfo - O  ((vid,((iid,cd?)|(cd,iid?))?) | (iid,((cd,vid?)|(vid,cd?))?) | (cd,((vid,iid?)|(iid,vid?))?))>

But for simplicity and readability we decided to recommend the following which actually allows more than one occurrence of each tag: 

	         <!ELEMENT pubinfo      - -  (vid|iid|cd)+>

In other words, DTD developers have always compromised; with XML, the compromises may just be different. On the other hand, W3C Schemas, described below, are so far from being human readable that there may be no point in attempting to improve readability with such simplifications.
And, on a positive note, when XML is introduced into the journal production process, several new tools become available to aid in validation. For example, an XSL style sheet could be used as a further validation checker for syntactic and semantic errors. 
The migration from XML to SGML will also encourage some publishers to use more self-explanatory markup.  This has been a trend in SGML journal DTDs over the last few years but is made simpler by the unlimited length of element names in XML. Historically, short element names have been used to save on re-keying costs. The BPG DTDs, for example, used the default SGML declaration which limited the length of element names. With the move to XML, BPG has "taken advantage to make the markup more self explanatory" [22], as can be seen in the replacement of the au element by the name element with its more descriptive content model.

W3C Schema
W3C schema, a W3C standard since May 2000 and the front-runner to replace DTDs, are far richer and enable more specific syntactic restrictions than DTDs (Ioannides, 2000). So, for publishers with concerns about content quality, there may be an argument for waiting until schema become well established and then moving directly from an SGML DTD to an XML schema, avoiding the intermediate step of the XML DTD. In the meantime, content could be converted to well-formed XML.
There is a variety of opinion among publishers as to whether conversion of their DTD to a W3C Schema is advantageous (Brown, 2002). The more XML-conversant publishers are following developments and waiting for the W3C Schema to establish itself more firmly. Some publishers have already identified advantages in its use. Patrick Thibor of Springer Verlag (personal communication, 1 March 2002), for example, is attracted by W3C Schema's ability to constrain element content more specifically; he feels this would "improve the quality of data" Springer receives from its suppliers. Bob Wittorf of OVID (personal communication, 5 March 2002) believes that the use of schema might improve validation. And the complex data typing enabled by schema is particularly useful in domains such as chemistry, as evinced by its use in the STMML language (Murray-Rust & Rzepa, 2002)
But many publishers are quite busy enough in converting operations to XML and do not perceive a compelling reason to take W3C Schema on board at the same time. As Murray-Rust and Rzepa (2002) point out "XML Schemas are complex"; a specification of over 300 pages and a primer of 60 pages may act as a deterrent to some.
Another disincentive, as pointed put by Schrauwen (personal communication, 10 August 2001) is that schema, as with many of the current developments in the XML arena, are of more advantage to metadata than in the structuring of continuous text. DTDs were designed for document-centric rather than data-centric systems; as far as the structuring of most journal articles goes, their replacement would ideally be document-centric too. W3C Schema may be ideal for journal metadata, but James Clark's schema language, Relax NG (Clark, 2001) might be a more suitable replacement for journal articles.

Benefits of XML for ejournals
Understandably, publishers tend to avoid the bleeding edge of technology and wait until standards are tried, tested and backed up with plenty of software before adopting them. As of December  2002, browser support for XML and its related standards by the two main browsers, Netscape and Microsoft Internet Explorer (IE), is improving rapidly after an unpromising start (Sall, 2002). Internet Explorer 6 has good support, as does the latest version of Mozilla [23;24], an open-source Web browser which provides a testbed for developments subsequently incorporated in the Netscape browser. The same is true for the W3C's [25] Amaya browser. And other XML-savvy browsers are emerging, such as X-Smiles [26]. But, as already implied, there is no need to wait for viable XML browsers before starting to use XML. There are growing incentives for publishers to introduce XML into the ejournal process, both at the metadata and the full text level, as now discussed.

XML METADATA 
It is the metadata portion of ejournal DTDs which gains the most attention and research. Here, XML facilitates many advances. The implications of XML for journal metadata is a huge subject and discussed in detail elsewhere (Cole et al., 2001; Rosenblum & Golfman, 2001) but consideration of just one example publisher gives a taste of some of the developments in this area.
The Nature Publishing Group (NPG) wants its article metadata and abstracts to appear in "as many places as scientists go to do their research" (Landolfi, J., personal communication, 17 August 2001). This information is made available to users via various abstracting and indexing services such as PMC, ISI, and ADS; currently, this is delivered in SGML, but NPG envisages migration to XML. NPG also sends a metadata feed to CrossRef [27]. (The CrossRef initiative, in which publishers exchange article metadata, is also XML based.) This data feed enables other primary research publishers to discover NPG Digital Object Identifiers (DOIs) and link their references directly to NPG content. NPG has seen an exponential growth in CrossRef related links since its inception at the beginning of 2001. 
Many publishers are now publishing articles on the Web some time before they are assigned to a print issue and given page numbers. 
The Nature Publishing Group's Advance Online Publication Program (AOP) is an example. In such a case, a DOI can be vital in identifying articles, for example for citation purposes. Here too, Nature plans to encoded in XML.
As Rosenblum and Golfman (2001, p.57) point out, "One of the most compelling reasons for electronic journals versus print journals is hyperlinks". Advances in linking between and within bibliographic databases, full text articles and supplementary journal material, such as multimedia, will be central to the future of ejournals. But what XML standards will drive these advances is not yet clear. Until recently, XLink and XPointer were the obvious candidates (Kim, 2000), with promises of two-way and multidirectional links. However, by December 2002 there were few XLink implementations, only very basic support in the Netscape and Mozilla browsers, no support in the Microsoft IE browser and apparently waning interest. The announcement by the W3C's HML Working Group of a rival HLink standard for use with XHTML 2.0 and the subsequent rejection of HLink by the W3C's Technical Architecture Group (Clark, 2002) has just added to the confusion. 
In the XML community, there is discussion as to whether the RDF and Topic Maps standards may fulfil the same needs as Xlink (DuCharme, 2002). It is interesting to note that Topic Maps, which provide for graphical navigation of Web sites, have already been adopted by HighWire [28]. 
Metadata is the ejournal component in which the use of one standard DTD might be most advantageous and least difficult. Although publishers include unique metadata elements that reflect their specific requirements (Rosenblum & Golfman, 2001), metadata tends to differ less between publishers than does full text markup. After all, many aggregators and other organisations, for example, CrossRef and the Open Archives Initiative [29] require metadata in a standard format. But commercial competition, combined with the relative ease of extraction of the relevant information from an XML file, mean that the increased sharing, transmission, linking and archiving of metadata is unlikely to result in one standard DTD. 

XML article full text 
Of equal interest to the markup of metadata, but less well aired elsewhere is the markup of full ejournal articles in XML. Here, XML acts as an alternative to formats such as PDF, HTML and Catchword's RealPage. One of the more high profile experiment in this area is the Illinois testbed (Cole et al., 2001).
It is interesting to note that discussions concerning development of the MAJOUR SGML header into a full-text DTD floundered in the early '90s because no one could think of a reason why publishers would want to exchange full text (Cave, 1998a). Views have certainly changed here; PMC and Elsevier require full text SGML or XML from their publishers and suppliers respectively. But, as regards delivery to the end user, XML's time may not be quite here. In 2001, EBSCOhost introduced full-text articles in XML [30]; in 2002, the company announced that it was abandoning this delivery format. As Brian Clark of EBSCO (personal communication, 19 March 2002) explained, "The problem for us using XML was that only IE browsers 5.0 and above could take advantage of this feature". 

MathML
The possibility of incorporating different XML languages within one document has huge implications for ejournals. One of the most exiting developments for display of scientific articles is MathML [31] which enables the inclusion of mathematical expressions in XML Web pages.
Among those publishers using SGML, the majority use the ISO 12083, AAP or Elsevier DTDs or the typesetting system TeX to model the mathematics found in journal articles (Rosenblum & Golfman, 2001). When it comes to display, however, equations are generally converted to an image, often a GIF. Cole et al (2001 p.213) comment that "one of the most problematical aspects of SGML full-text rendering [in the Illinois DLI-I Testbed] has been accurately rendering SGML marked-up display mathematics". MathML should solve many of these problems.
There are two styles of encoding possible using MathML: Content encoding which concentrates on semantic meaning and the simpler Presentation encoding which concentrates on display. W3C's Amaya browser can already render Presentation MathML, as can Mozilla and, more recently, Netscape 7.0. There is no native support for MathML in Microsoft IE as yet but it appears that it is only a matter of time. This is despite earlier reservations on the part of Microsoft that Mathematical content "is not applicable to everyone and could be a heavy burden to pay every time you fired up your Web browser" (Massy, 2001). In the meantime, there are a variety of browser extensions that will display MathML within XHTML files, including IBM Techexplorer, WebEQ and MathPlayer [32]. As of March 2002, the Math working group of the W3C have made available a "'universal MathML style sheet'  which makes it possible to author a single form of HTML + MathML that will be viewable in many browsers, including IE5.5, IE6 and Mozilla" [31]. This style sheet is, in fact an eXtensible Style Sheet Language Transformation (XSLT) and so requires at least version 6.1 of Netscape or IE 5.5 with the Microsoft XML version 3 parser [32]. 
Several publishers are planning to convert to MathML in the near or longer term as part of their SGML to XML conversion. Blackwells and Elsevier have already done this. Elsevier "amended" the MathML standard to support features such as clickable cross-references within the text portions of formulae (Schrauwen, R., personal communication, 11 December 2002). At present, IoPP is not using MathML but its XML DTD is designed in such a way that "it can be simply included when [IoPP] feels it would be advantageous to use it" (Cox, T., personal communication, 10 December 2002). AIP, had planned to use a modified version of the mathematical tagging structures within the 12083 SGML DTD while monitoring the progress of technologies such as MathML and implementing them "when practical” (McMahon, C., personal communication, 16 August 2001). Practicality included the "availability of appropriate software to aid in the journal production process". These tools are now available and AIP will be implementing MathML (McMahon, C., personal communication, 11 December 2002).

Other XML languages
Whereas most STM publisher DTDs have some mathematical markup capability, the markup of chemical components is still at a more experimental stage. The RSC's New Journal of Chemistry has been experimenting with the delivery of supplemental information in CML (Kidd & Harlow, 2001). The latter provides "tags for describing chemical entities – such as atoms and bonds – in a way that enables them to be recognised, presented and manipulated as such within a Web-based browser" (Spedding, 2002). Again, support by the major browsers is still in flux, although CML is displayed by Mozilla and IE 6 using an appropriate style sheet and an SVG plugin. Interestingly, Rob Schrauwen of Elsevier  (Schrauwen,R. personal communication, 11 December 2002) comments that “CML is of no use to us, as our suppliers are not able to tag the structure of a chemical formula, only the presentation”. As already mentioned, MathML enables both content and presentation encoding.

One of the XML languages in which there is most interest in journal publishing for the representation of both graphics and full article pages images is Scalable Vector Graphics (SVG) [34]. Murray-Rust and Rzepa (2002) comment that "The increasing adoption of e.g. Scalable Vector Graphics (SVG) is an excellent development and we recommend that graphical information is encoded this way rather than as raster images whenever possible." In relation to page images, ingenta [6] has recently begun to make full text articles available in SVG.
And there are rumours of interest in SVG as a replacement for PDF by at least one major publisher (Wilson, M., personal communication, 30 May 2002). A non-proprietary XML-based alternative to PDF can only be good news.
Again, native support for SVG by the big two browsers is not here yet, although Mozilla 0.9.9 and above, Amaya and X-Smiles already display it. There are a number of standalone SVG viewers as well as a browser plug-in by Adobe [33]; the latter is being used in the ingenta system. SVG is increasingly being regarded as a potentially useful display format for material stored in other XML languages; MathML and CML are just two examples where SVG converters already exist [35;36].
SVG is also a potential rival to Macromedia Flash for display of animations. This will not have an immediate impact on ejournals as Flash is rarely used here. As Bide (2000 p.18) comments, although there is a marked increase in the supplementary material, such as multimedia, made available with journals, there is "little consistency" in the formats used. At present, most publishers just accept whatever formats the authors provide. The XML application SMIL (Synchronized Multimedia Integration Language) [37] that enables "simple authoring of interactive audiovisual presentations" has obvious implications for ejournals but there are, as yet, no examples of its use in this field (McKiernan, 2002).

CONCLUSION
The use of XML is slowly permeating all aspects of the electronic library. The move away from the proprietary formats of traditional library systems and towards the future-proof platform-independent XML is vital if we are not to restrict the potential of future library-based information..
Most players in the journals market recognise the importance of XML; many regard it as central to the future of the ejournals process. The current proposals for XML as an ejournal archival format will serve to increase this interest. Support for XML in current browsers is not comprehensive enough to make article display in XML a serious option for most publishers and aggregators as yet; the exception here is the use of SVG for page images.  But within ejournal development and dissemination as a whole, XML will be used at an increasing number of stages. 
XML has the potential to facilitate many features which will add value to the ejournal. Some obvious applications include projects such as the W3C's Annotea [38], which enables the creation of Web page annotations using RDF and XPointer; its use could facilitate online peer review. There is enormous potential for XML to enable the repurposing of ejournal components; powerful XML tools such as XSLT will be of central importance here. Cole et al. (2001) describe experiments to generate different views of the same article and metadata. One of the most important XML advances for ejournals will be in inter and intra-document linking: what standards will predominate here is still not clear. No doubt, the relevance to ejournals of many emerging XML standards will become apparent and, in time, these standards will be adopted by providers of ejournals. Murray-Rust's vision is ambitious but not impossible:
"Imagine what would happen if all scientists published their results directly to the community in XML. [Software] agents could ultimately analyse every element of that paper" (Spedding, 2002).

NOTES
[1] Swets Blackwell: 
http://www.swetsblackwell.com/about.htm
[2] EBSCO: http://www.ebsco.com/ 
[3] Divine: http://www.divine.com/
[4] Elsevier Science Direct: http://www.sciencedirect.com
[5] Wiley InterScience: http://www.interscience.wiley.com/
[6] ingenta: http:www.ingenta.com
[7] OCLC First Search Electronic Collections Online: http://www.oclc.org/oclc/menu/eco.htm
[8] American Institute of Physics: http: http://www.aip.org/
[9] ISO 12083 Information: http://www.xmlxperts.com/12083.htm
[10] European Workgroup on SGML (EWS): http://xml.coverpages.org/ews.html
[11]Simplified SGML for Serial Headers: http://www.franciscave.com/sssh/
[12] Springer Verlag: Electronic Technologies: http://devel.springer.de/
[13] The SuperJournal Project: http://www.mimas.ac.uk/sj/
[14] Infobike: http://www.bids.ac.uk/elib/infobike/homepage.html
[15] Elsevier Science DTDs: 
http://www.elsevier.com/locate/sgml
[16] PubMed Central Information for Publishers: http://www.pubmedcentral.nih.gov/about/pubinfo.html 
[17] Openly Informatics, Inc: XML Publishing: http://www.openly.com/efirst/
[18] Royal Society of Chemistry: http://www.rsc.org/
[19] Blackwell Publishing DTD 4 Documentation: http://www.blackwell-science.com/dtds/4-0/bpg4-0help/default.htm
[20] HTML Tidy: http://tidy.sourceforge.net/ 
[21] Blackwell Publishing DTD 4 Documentation: How to Read a Content Model: http://www.blackwell-science.com/dtds/4-0/bpg4-0help/contmod.htm
[22] Blackwell Publishing DTD 4 Documentation: FAQ: http://www.blackwell-science.com/dtds/4-0/bpg4-0help/faq.htm
[23] Mozilla.org at a glance: http://www.mozilla.org/mozorg.html
[24] XML in Mozilla: http://www.mozilla.org/newlayout/xml/
[25] Amaya: http://www.w3.org/Amaya/
[26] X-Smiles: http://www.x-smiles.org/xsmiles_objectives.html
[27] Crossref: http://www.crossref.org/
[28] Topic Map in Highwire: http://highwire.stanford.edu/help/hbt/
[29] Open Archives Initiative: http://www.openarchives.org/
[30] EBSCO Press Release March 15 2001: http://www-uk.ebsco.com/home/whatsnew/ehost44.stm
[31] MathML: http://www.w3.org/Math/
[32] XSLT stylesheets for MathML: Publishing XHTML+MathML Documents on the Web: http://www.w3.org/Math/XSL/overview-tech.html
[33] Adobe SVG Viewer: http://www.adobe.com/svg/viewer/install/main.html
[34] Scalable Vector Graphics: http://www.w3.org/Graphics/SVG/
[35] MathML to SVG converter: http://www.schemasoft.com/MathML/
[36] Adobe SVG Zone: http://www.adobe.com/svg/demos/devtrack/chemical.html
[37] W3C SMIL: http://www.w3.org/AudioVideo/
[38] Annotea Project: http://www.w3.org/2001/Annotea/

REFERENCES:
Apps, A. and MacIntyre, R. (August2000), "XML: Using an Evolving Standard in Electronic Publishing", Electronic Publishing 2000, Kaliningrad.
Bide, M. (August 2000), "Standards for Electronic Publishing: An Overview. A report for the NEDLIB Project", Available (NEDLIB) http://www.kb.nl/coop/nedlib/results/NEDLIBe-publishing.pdf
Brown, A. (20-23 May 2002), "XSD Schemas in Book and Journal Publishing", XML Europe 2002, Barcelona, Spain. Available (IDEALLiance) http://www.idealliance.org/papers/xmle02/
Cave, F.J. (July 1998a), "SGML in Scientific Publishing - An Introduction", InterCHANGE: The Newsletter of the International SGML/XML User's Group, Vol. 4, No. 3, pp. 16-17.
Cave, F.J. (July 1998b), "SGML in Scientific Publishing - Part 2", InterCHANGE: The Newsletter of the International SGML/XML User's Group, Vol. 4, No. 4, pp. 10-12.
Clark, J. (25 May 2001), "RELAX NG Tutorial"
 OASIS Working Draft, Available (OASIS) http://lists.oasis-open.org/archives/relax-ng/200105/msg00291.html
Clark, K.G. (2 October 2002), "TAG rejects HLink", XML.com, Available: http://www.xml.com/pub/a/2002/10/02/deviant.html
Cole, T.W., Mischo, W.H., Habing, T.G. and Ferrer, R.H. (2001), "Using XML and XSLT to process and render online journals", Library Hi Tech, Vol. 19, No. 3, pp. 210-222.
Dumbill, E. (19 December 2001), "Clark Challenges the XML Community" XML.com, Available: http://www.xml.com/pub/a/2001/12/19/jjc.html
DuCharme, B. (13 March 2002),"XLink: Who Cares?", XML.com, Available (XML.com) http://www.xml.com/pub/a/2002/03/13/xlink.html
Hickey, T. B. (1994), "Integrating Guidon with the World Wide Web",Annual Review of OCLC Research 1994, Available: http://www.oclc.org/research/publications/arr/1994/part1/integuid.htm
Huber, C.F. (Summer 2000),"Electronic Journal Publishers: A Reference Librarian's Guide", Issues in Science and Technology Librarianship.
Ioannides, D. (2000), "XML schema languages: beyond DTD", Library Hi Tech, Vol. 18, No. 1, pp. 9-14.
Kidd, H. and Harlow, K. (March 2001), Editor's comment on article by Murray-Rust, P., Rzepa, H.S. and Wright, M., "Development of Chemical Markup Language (CML) as a System for Handling Complex Chemical Content", New Journal of Chemistry, Royal Society of Chemistry, Available: http://www.rsc.org/suppdata/NJ/B0/B008780G/comments.htm
Kim, H. Choi, C. (2000), "XML: how it will be applied to digital library systems", The Electronic Library, Vol. 18, No. 3, pp. 183-189.
Massy, D. (26 March 2001), "Internet Explorer 6 and Standards" Microsoft Corporation, Available: http://msdn.microsoft.com/library/en-us/dndude/html/dude03262001.asp
McKiernan, G. (18 February 2002), "SMIL E-Journal Examples" Email from gmckiern@gwgate.lib.iastate.edu, Sent to 
       LIS-ELIB@JISCMAIL.AC.UK.
Murray-Rust, P. and Rzepa, H. S. (February 2002), "STMML. A Modular XML-Based Markup Language for use in Scientific, Technical and Medical Publishing", Available: www.xml-cml.org : What's New
Nature (2001), "Opinion - The future of the electronic scientific literature" Vol. 413, Sept 6, pp.1-3.
Pepping, S. and Schrauwen, R. (March 2001), "Tag by Tag: The Elsevier Science Full-Length Article DTDs 4.1-4.3",Version 1. Available: http://www.elsevier.com/locate/sgml
Rosenblum, B. and Golfman, I. (5 December 2001), "E-Journal Archive DTD Feasibility Study", Prepared by Inera Inc. for Harvard University Library Office for Information Systems E-Journal Archiving Project. Available: http://www.diglib.org/preserve/hadtdfs.pdf
Sall, K. (22 May 2002), "XML Software Guide: XML Browsers", Web Developer's Virtual Library. Available: http://www.wdvl.com/Software/XML/browsers.html.
Smith, A. (2001), "Long Term Archiving of Digital Documents in Physics: Meeting Report", November 5-6, Lyon Villeurbanne. Available : http://publish.aps.org/IUPAP/
Spedding, V. (25 February 2002), "Frontiers: XML to take Science by Storm" Scientific Computing World, Cambridge Publishers Ltd. Available: http://www.researchinformation.info/
       feature2.html 
Wusteman, J. (14-16 April 1997), "The Evolving Use of SGML in Electronic Journals'', Electronic Publishing '97: New Models and Opportunities (ICCC/IFIP), University of Kent at Canterbury. 

Library

Printer

Typesetter 

Reviewers

Author

Aggregator

Publisher/
Editor

Users

Production Company

Copy Editors

Other publishers

FIGURE 1: Information flow between players in ejournal production and delivery