summaryrefslogtreecommitdiff
path: root/usergrps/uktug/baskervi/6_3/conf.tex
diff options
context:
space:
mode:
Diffstat (limited to 'usergrps/uktug/baskervi/6_3/conf.tex')
-rw-r--r--usergrps/uktug/baskervi/6_3/conf.tex234
1 files changed, 234 insertions, 0 deletions
diff --git a/usergrps/uktug/baskervi/6_3/conf.tex b/usergrps/uktug/baskervi/6_3/conf.tex
new file mode 100644
index 0000000000..ba8a94f411
--- /dev/null
+++ b/usergrps/uktug/baskervi/6_3/conf.tex
@@ -0,0 +1,234 @@
+\MakeShortVerb{\|}
+\title{Portable Documents: What Next?}
+\author{Frank Harwood}
+%(omits Klaus' talk, as I arranged with him: since Tardival
+%provided her own report, you could also omit his summary of that)
+\begin{Article}
+\subsection{Introduction}
+%(I have to write this $\ldots$)
+This article is a summary of the conference held on 15~February 1996
+by the British
+Computer Society Electronic Publishing Specialist Group in
+conjunction with \ukt\ continuing the `portable documents' theme.
+The two previous articles on Euromath and Hyper-G also cover papers
+presented at this conference and so are not mentioned in this
+summary.
+
+\section{What Next?}
+\subsection{Les Carr, University of Southampton}
+
+``Now we have them, how do we use them/maximise the benefit?''
+was the theme of Les's talk. We have available a spectrum of
+portable formats, from \texttt{.PDF} with high visual fidelity, to \acro{SGML}
+which preserves logic of content without reference to
+appearance. (The intriguing question was floated and left
+open, that although we have a large measure of portability
+between systems -- do we have temporal portability? -- can I
+read today's electronic document in 30 years time?)
+
+Documents are now available from around the globe, and to be
+most useful need links between them. Hypertext-type linking
+is found in personal systems (e.g., Guide, Hypercard) through to
+global systems (e.g., \acro{WWW}), but to a degree, all are `closed' -- a
+non-universal and therefore `proprietary' markup is used which
+does not extend into other people's systems.
+
+The Microcosm Model (at Southampton) separates the document
+control system (how to produce and display it), from the link
+control system. Links are any type of relationship between
+documents, and flexible link definitions are allowed for. The
+Open Journals Project, funded by \acro{JISC}, applies Microcosm
+technology to \acro{WWW}. It is possible to integrate on-line
+journals with each other and with various on-line databases
+and teaching resources. The concept of a document becomes
+very broad indeed and the databases of links (linkbases)
+become value added commodities in their own right. Linkbases
+are configurable for different levels and purposes. This
+could be seen as opening a new publishing idiom where the
+various `closed' technologies mentioned become local and short
+term solutions.
+
+See it at \url{http://journals.ecs.soton.ac.uk/}
+
+\section{Converting from \LaTeX\ to SGML}
+
+\subsection{Sebastian Rahtz, Elsevier Science}
+
+An in-depth review, heavily illustrated with examples, was
+given by Sebastian, discussing the problem, various feasible
+approaches, and demonstrating results so far produced at
+Elsevier (package not in the public domain).
+
+The publisher faces a large community using \LaTeX, a mature
+notation and free typesetting system, well suited to
+scientific and multi-lingual work. Unfortunately, it is not
+what the publisher uses, not an international standard and
+does not convert for various purposes as does \acro{SGML}.
+
+Four practical approaches were mentioned:
+\begin{enumerate}
+\item Throw away electronic file and retype.
+\item Strip out \TeX\ coding and treat as unknown word processor.
+\item Write program to parse \LaTeX\ and output \acro{SGML}.
+\item Re-implement \TeX\ to output \acro{SGML} codes.
+\end{enumerate}
+of which the first two were not discussed.
+
+The parser approach has been implemented a number of ways but
+can only be partially successful because \TeX\ is macro based
+with extensible syntax. All results so far require afterwork
+to tidy up. To implement route 4, three methods have been
+used.
+\begin{enumerate}
+\item Replace \TeX\ backend
+\item Rewrite \TeX\ in a new language -- has been done in \acro{LISP}
+\item Write \acro{SGML} code to the dvi file and extract it from there -- used
+by Elsevier.
+\end{enumerate}
+
+The work done was described in detail stressing the importance
+of the target \acro{DTD} and the richness of the \LaTeX, highlighting
+also a number of pitfalls. The acid test is that it works and
+real scientific papers can be translated, though human
+intervention at some level is frequently needed to perfect the
+end product.
+
+For more detail, see \TUB\ 16.3.
+
+\section{\acro{SGML} is here}
+
+\subsection{Andrew Dorward and Neil Bradley, Pindar}
+
+Substituting for the speaker originally planned, Andrew and
+Neil gave a lightning rendition of the \acro{SGML} story -- %
+principles, implementation considerations, current
+developments and criteria for use or rejection!
+
+The principles of \acro{SGML} are well understood within the group. It
+is an open system, defined by \acro{ISO}\,8879 (1986). There has been
+a recent expansion of interest, triggered by \acro{HTML} -- restricted
+and non-open. The current state of play is that \acro{SGML} is used
+for many more `pages', but has a lower profile. Recent
+developments, particularly \acro{DSSSL} and Hytime provide
+enhancements to the use of \acro{SGML}. Although \acro{SGML} is independent
+of any software publishers, there are numerous products around -- parsers,
+editors and \acro{DTD} tools, and in a production
+situation it makes sense to adopt the best available. The
+new Frame \acro{SGML} software suite -- just out of beta-test and
+becoming available now, was strongly recommended.
+
+Implementation considerations were discussed using a markup of
+an article as an example. Whereas the considerations are the
+same whatever the task, the use of appropriate software can
+aid efficiency, reduce errors and give more options on the use
+of tagged data and the control of style.
+
+Take account of:
+\begin{description}
+\item[``Granularity''] -- how far to break down the material. High
+granularity $=$ a fine breakdown. This adds value to the
+information at a price (in effort) and should be chosen
+appropriate to purpose.
+
+\item[``Hierarchy''] -- markup objects can contain other markup
+objects. Many levels are possible. Again this needs to
+be set appropriate to material and purpose.
+
+\item[``Attributes''] -- e.g., use of |<name 'personal'>| and
+|<name 'company'>| can enable separate listing.
+
+\item[``Hypertext''] -- the setting up of cross-reference jumps
+from one point in the text to another, internal or
+external to the document or database. Here again the
+software used can greatly facilitate the process.
+
+\item[\acro{DTD}] -- the Document Type Definition controls granularity,
+quality, optional/mandatory items, alternatives,
+sequences, element names. A visual \acro{DTD} tool such as
+``Near and Far'' makes for faster and more accurate
+production of \acro{DTD}s.
+
+\item[Authoring Environment] -- may be structured (software from
+Frame, SoftQuad) where the authoring process is
+interactively constrained according to the \acro{DTD}, or
+`loose' (software from Microsoft or other out-of-line
+parsers).
+\end{description}
+
+There is a checklist of reasons to adopt \acro{SGML}. With two ticks
+against the list \acro{SGML} should be considered, with four ticks,
+it would be very foolish not to use it.
+\begin{itemize}
+\item[--]long shelf life data? (\acro{SGML} is too expensive for transient
+data)
+\item[--]for multiple media publication?
+\item[--]frequent republication?
+\item[--]need searchable database?
+\item[--]for inter-department or inter-company exchange?
+\item[--]new product extraction from existing data?
+\item[--]need heavy hypertext?
+\item[--]industry requirement?
+\end{itemize}
+
+A fictional ``must use'' example was given. A Company with a
+body of high value articles wishes to publish on hard copy,
+\acro{CD}-\acro{ROM}, \acro{WWW}, also abstracts, also lists of articles and
+contributors as separate products. All can be pulled out with
+little effort after the initial investment in \acro{SGML}.
+
+
+\section{Java -- The Krakatoa of the Web}
+
+\subsection{Henry Rzepa, Imperial College, London}
+
+This item outlined a particular body of work done at Imperial
+College before the appearance of Java, the improvements made
+possible by Java, and some informed speculation on future
+developments.
+
+Work started in 1994 to try to publish representations of 3\acro{D}
+molecular structures (\acro{MIME} type). The concept was to be able
+to click on a hyperlink and get a 3\acro{D} rotatable model within a
+2\acro{D} document. This required a marked up dataset defining the
+model and a script on the user's computer which read and
+interpreted the markup. A result which worked was achieved,
+albeit with non-standard components and on Unix only. When
+\acro{VRML} was brought into use in March 1995, improved
+communication between the 3\acro{D} model and 2\acro{D} document resulted,
+but the whole was still non-standard and Unix only.
+
+The introduction of the Java language to the project in July
+1995 achieved a seamless interface between the \acro{WWW} client,
+data and action, and seamless memory and security models for
+the whole ``document''. Not only did this fulfill the original
+concept elegantly, but extra features became possible.
+Rotatable models of various representations could be
+interchanged and extra information delivered, e.g.\ by clicking
+on certain points of the model, Java applets could be invoked
+which delivered inter-atomic distances.
+
+Java in its present form, as a \acro{C}++ like language, is a
+powerful tool, used as directed, and had a major impact on
+this particular project. There are plans to use the project
+as a basis for an electronic conference in June 1996. Its
+full features are available on Unix and Windows~95 platforms
+only, and whereas this accounts for 90\% of visitors to
+Imperial's web site, it really needs Windows 3.1 and Mac
+versions for universal take-up. There is also mileage to be
+had from a future integration of \acro{VRML} with Java. Apple's
+CyberDog is an alternative but may be released 2 years too
+late for acceptance.
+
+There are, of course, problems. Already it appears that early
+Java applets are not compatible with later; a serious flaw
+which must be addressed before Java can become a mainstream
+language/method. For publishing/\acro{WWW} applications there is a
+particular danger that data incorporated within applets will
+``disappear'' in the sense that it will not be searchable as is
+HTML data.
+
+See it (and rotate it!) on:
+
+\url{http://WWW.ch.ic.ac.uk/java/java_1.html}
+
+\end{Article}