Second Forum on Parallel Computing Curricula
Sunday, June 22, 1997
This document provides general guidelines for the final versions of papers for FPCC: The Second Forum on Parallel Computing Curricula [Kotz97]. Our primary goal is to have a uniform look to the papers in the proceedings. We have chosen for a simple layout for papers so as to support the greatest number of browsers.
The program committee of the Second Forum on Parallel Computing Curricula has chosen to provide a web-only proceedings for the forum. There are a number of reasons for this decision, but wide accessibility is perhaps primary among them. This document is designed to help authors prepare uniform papers for the proceedings.
that all papers be prepared in HTML. If you do not know HTML, please
contact the proceedings chair, Sam Rebelsky (
and he will aid you in your translation.
Although you are free to keep a copy of your paper on your own server, in whatever format you wish, we also intend to keep a permanent copy on the FPCC server. Please get the final version of your paper to Sam Rebelsky by June 1 so that the papers can be made available in time for the forum.
Because many readers will print your paper, we request that papers be prepared as one long HTML document. If necessary, we will segment your papers for online viewing.
We prefer information-oriented rather than layout-oriented papers. Hence, please do not use frames, and only use tables when they are tables that form part of your paper. You may feel free to include inlined images in your HTML documents.
Papers are to be prepared in the standard "research paper" order:
The following lines provide suggestions (which we would prefer that you follow) on how to format individual portions of your document. They are in alphabetical order for easy reference. You may refer to the list describing the order of components that appears above to determine what you might need to consider in formatting your paper.
Note that this set of guidelines follows the guidelines for FPCC (that is, this should look more-or-less the same as this paper, with obvious differences due to content and intent).
DL). Each author's name should be prefaced by a
DTtag and each line of the address should be prefaced by a
DL) for the bibliography.
DTtag and the reference "body" with the
CODEtag. For long sections of code, you should use the
</P>: tags. Do not use
<P>to separate paragraphs. For lists, do what you think is best (I've chosen to treat my list as one paragraph; you may choose to make each item a separate paragraph).
H2tags for section titles,
H3tags for subsections, and so on and so forth.
H1for your document title in the body of the document. You will probably use a slightly different title in the header, preferably the last name of the authors and an abbreviated version of the document title.
In our experience, bibliographies are quite inconsistent and have gotten even more so with the introduction of electronic documents and markup languages.
HTML has the added disadvantage that it does not include specific bibliography tags, such as <bibentry>, or <journaltitle>. We believe that the format we have chosen (which can be identified by looking at the source of this document) serves many of the needs of readers and writers.
Of course, HTML and the WWW provide more opportunities for bibliography usage and we strongly encourage authors to make the references in the body of their text links to the bibliography. In addition, any references to online documents in the bibliography should be links to those documents.
We encourage, but do not require, the abbreviated name/year format for labeling bibliography entries. It is sufficiently small not to impede the flow of text, but provides sufficient information that readers need not always look to the bibliography. We recommend against numbers, as they are hard to distinguish from footnotes .
The following are samples of various types of references to help you use a uniform format for references. See the source code for this document to see how they are annotated.
Try to follow the models above for other types of documents. In general, we request that you
These are intended to provide a short summary of some of the issues described above. They also try to provide some motivation for a few particular issues.
firstname.lastname@example.org). If using more than one file, tar and uuencode everything before sending.
<P>to separate paragraphs.
</PRE>tags at the end of your document. This makes it easier for some browsers to correctly link to pieces of text at the end of your document. Note that the
PREtags should each by on their own line.
 The brackets around an end note number make it easier to identify as such.
 Now, didn't that look a little like a reference?