A SOFTWARE ARCHITECTURE FOR SUPPORTING THE EXCHANGE OF ELECTRONIC MANUSCRIPTS
AUTHORS: MAMRAK, KAELBLING, NICHOLAS, SHARE

Group 2
Lauren Barton
Martin Falck
Nelson Kile
Carolyn O'Hare
Robert Ryan

This article discusses the Chameleon project at Ohio State that was, at the 
time the was written, developing an architecture to build tools that would 
translate between different protocols.  In the long run, the goal of this 
project was to develop a product that will build translation tools.  These 
tools are to be maintenance and user friendly.

There would be two tools developed:
     * A tool for translation from a standard into a non standard form (down 
translator).
     * A tool for translation from a non standard for to a standard form (up 
translator).

The purpose for building these tools was to make conversions easier.  There 
are numerous electronic manuscript representations possible which presents 
an obstacle to electronic exchange of the documents  This is since different 
text formats require unique software to read them.  One solution to this is 
to develop computer systems that can facilitate translation into and from a 
standard form.

There are some specific software packages that currently translate between 
different standards, but these only deal with format and not structure.  
This project would tackle the problem of building automatic translation 
systems to and from standard forms.

The standard form (generic language) was based on the Standard Generalized 
Markup Language (SGML) with formatting information added.

The system would support the development of software for both the build and 
use phases of translation systems.  The architecture also relied on 
attribute grammars to specify a translation.

=============================================================

From: (Group 5)
        Shirley Carr
        Mike Joyce
        Bushra Khan
        Zakia Khan
        Vas Madhava
                       Article Summary: MAMR87

        As electronic exchange of manuscripts becomes more of a
reality, problems arise because of the various formats that exist.  
The obvious solution is to use a single format, but even that
solution is problematic because there will likely be many "dialects"
of that format.  There are already many standards that exist and
translation between them is already a problem.  In addition, there are
many documents that are on paper.  They need to be scanned in and
stored electronically and the issue of what format to use arises
again.

        The authors propose a two-part solution: First is the use of
translation tools.  This would be good for the short term only.
Second, they propose an integrated system to build these tools.  So
far, no systems exist for the translation from one electronic format
to another.  Word processor translators deal with formatting and don't
address the content and structure issues.  Recent trends in this field
have been in going from a standard form to various internal forms.
The entire topic of translation has been of great interest to CS
types.

	The article presents an overview of the Chameleon project at
Ohio State University. The project is investigating the translation of
the formatting information used to control the electronic
representation of documents and tools to support the translation
process.  The specific goals of the Chameleon project are to:

1) Build a software system that:
   a) Supports programmers in _building_ tools to do translation.
   b) Helps in _using_ those tools to translate manuscripts.

2) From a long term perspective, to make maintenance and use of
   translation systems easily available to programmers and users by:
   a) Increasing on-line assistance for constructing and using
      translators. 
   b) Hiding the underlying data abstractions.


	The project recognizes two aspects to the translation problem.  
The first, called translation up, is the translation of a document from
a non-standard format to a standard format.  In this case, a non-standard
format could be a proprietary format used by a word processing vendor
or another standard format.  Experience indicates that this translation
process needs manual assistance because of the potential ambiguity of
formatting and structural informational.

	The other aspect of translation is called translation down.
This process involves the translation of a document from a standard format
to some other representation.  Unlike the translation up process, the
translation process can be done automatically, although in some cases
arbitrary choices must be made if there is no non-standard form
available for a standard form.

        Currently the authors have built a translation-down system in
cooperation with the American Chemical Society, based on SGML.  SGML
based forms are context free grammars that describe manuscripts as
hierarchical objects.  It has broad-based support, both in the US
(DoD, IRS, NIST, etc) and internationally.  The prototype system has
the following features:
        1) It has support for both the build phase and the use phase.
        2) It has simultaneous support for translation in both
           directions.  Based on Yellin and Mueckstein's work, an
           inverse translator can be generated once it has been done
           in one direction.
        3) It is geared towards application-oriented end users.
           Thus user-friendly interfaces have been developed.
        4) It is designed to accommodate model updates.  Thus when
           changes occur, the system can easily be updated to
           regenerate all the necessary tools.
        5) It exploits existing tools that are on the market.
        6) It fits in with all the other work that is going on that
           deals with electronic manuscripts.


The tools needed for building a system like this are:
        1) A Translator Writer which takes a high level specification of
           the translation and generates an attribute grammar.

        2) A Translator Inverter which takes the attribute grammar and
           generates another one for the inverse.

        3) An SGML Scanner/Grammar Generator which takes a description of
           an SGML application and generates a scanner for it and a
           modified version of its grammar.

        4) A Nonstandard Form Scanner Generator which takes a
           description of the translation and generates a nonstandard
           form scanner.

        5) A Form Screen Generator that takes standard and nonstandard
           form grammars and generates user-assisted translation-up
           software.

        6) A Translator Generator that takes an attribute grammar and
           generates code to implement the translation.

Existing tools are inadequate for building such a system because:
        a) They don't handle SGML.
        b) They have poor performance
        c) They require expert knowledge.