Checklist for approving UTRs, UTSs
and UAXs for
posting
Including instructions for
creating and reviewing drafts
last modified: 2008-06-11 rick
This checklist focuses on formal checking of format
for publication release and does not contain issues for content
review. Where they are intermixed with sample text, instructions to the reviewer are given in blue,
and in a serifed font. Some designations of draft status are shown in
red as they would be in the actual
document.
The following Checklist instructions are interspersed with
sample text from TR documents for ease of use. A complete summary of all checklist items, especially for the TR
body, may be found in Section 1, The Checklist.
- Check the page title. It's shown on browser
title bar, and is in <title>...</title> in HTML. This is easy
to forget. Don't use different titles for proposed/draft -- just use the
final title. The title can be abbreviated, here are three examples for the
three types of documents:
-
UTR #36: Unicode Security
Considerations
-
UTS #18: Unicode Regular
Expressions
-
UAX #14: Line Breaking Properties
-
UTR #25: Unicode Support
for Mathematics (PDF format)
- Make sure that Unicode Standard Annexes use UAX
and Unicode Technical Standards use UTS instead of UTR
- Check overall TR format. The Bar should
look like the above. The words
"Technical Reports" should link to the main reports page
-
Check the left margin. From this point, the TR body should be
enclosed in a <div class="body"> element in order to provide a
left margin. (This TR template has such a body element.)
-
Check status designation (showing
on of Draft or Proposed Draft, Proposed Update in red, or nothing) in the title.
-
Check the formatting of the title,
as in these examples:
Proposed Update Unicode
Standard Annex #14
LINE BREAKING PROPERTIES
Draft Unicode Technical
Report #36
Unicode Security Considerations
-
Check header table contents
and format - table must neither be 100%, nor use fixed pixels or it will
not display/print correctly (the table below uses 95% width):
-
The following shows the header
format for the three types of documents.
8a. UAXs, when updated, should have the
full three digit version
number of the future Unicode Version, with the word '(draft)' in red. UAXs must have a
revision number that is incremented each time and must
match the file name in the versions.
8b. UTSs normally have a two field version
number and a revision number. The revision number is increased for
each public
draft and version, the version is incremented only for approved
versions. In exceptional circumstances a third field can be
used, preferably only for UTSs of major complexity, or if an
update is really miniscule but required. (UTS #10 is an
exception: it should have a 3-digit version number,
corresponding to the version of Unicode to which it is
synchronized.)
8c. UTRs only have a single revision number without
dots.
-
The following are optional fields for standards that
implement DTDs. The are inserted above "Revision".
-
The following
The following is an optional field, for standards that require
public access to working drafts. Working drafts are not
versioned, and are not maintained in the trxx folder. If a working draft
exist, a copy of the working draft resides in
http://www.unicode.org/reports/trxx/workingdraft.html.
When no working draft exists, that URL points to an empty placeholder
file. [Usually, immediately after the release of a public version, the
working draft would be a placeholder]. If used, it is inserted
immediately above "Revision".
Summary
- All reports must have a brief summary.
- Text of the Summary and Status sections should be
italic.
Starting with version 3.2, Unicode includes virtually all of the
standard characters used in mathematics [.. additional
sample text elided...]. This technical report describes
the Unicode mathematics character groups and gives some of their default math
properties.
Status
- Check that status section matches status in
title, either Draft, Proposed Draft, Proposed Update, or final (text must
match the sample text given here)
Make sure that the correct committee is used.
This document has been reviewed by Unicode members and other interested
parties, and has been approved for publication by the Unicode Consortium.
This is a stable document and may be used as reference material or cited as a
normative reference by other specifications.
| Alternate Paragraph for not-yet
approved documents. Replace the above if needed, and copy just the
information from the following cell, without the table
formatting. Keep the red. |
| This is a draft
document which may be updated, replaced, or
superseded by other documents at any time. Publication does not imply endorsement by the Unicode Consortium. This is not a stable document; it is
inappropriate to cite this document as other than a work in progress. |
A Unicode Standard Annex (UAX) forms an integral part of the
Unicode Standard, but is published as a separate document. The Unicode
Standard may require conformance to normative content in a Unicode Standard
Annex, if so specified in the Conformance chapter of that version of the
Unicode Standard. The version number of a UAX document corresponds to the
version number of the Unicode Standard at the last point that the UAX
document was updated.
| Alternate Paragraphs for other
types of TRs. These replace the above as needed. (Discard the table
formating) |
| A Unicode Technical Standard (UTS) is an
independent specification. Conformance to the Unicode Standard does
not imply conformance to any UTS. |
| A Unicode Technical Report (UTR)
contains
informative material. Conformance to the Unicode Standard does not
imply conformance to any UTR. Other specifications, however, are
free to make normative references to a UTR. |
The "corrigenda"
paragraph in the Status section should follow the above "type" paragraphs.
The corrigenda information differs between UAXes and other types of reports.
For UAXes, use this
paragraph:
Please submit corrigenda and other comments with the online reporting
form [Feedback]. Related information that is useful
in understanding this annex is found in Unicode Standard Annex #41, “Common References for Unicode Standard Annexes.”
For the latest version of the Unicode Standard, see [Unicode].
For a list of current Unicode Technical Reports, see [Reports].
For more information about versions of the Unicode Standard, see [Versions].
For any errata which may apply to this annex, see [Errata].
|
|
For UTRs and UTSes,
use this paragraph:
Please submit corrigenda and other comments with the online reporting
form [Feedback]. Related information that is useful in
understanding this document is found in the
References.
For the latest version of the Unicode Standard see [Unicode].
For a list of current Unicode Technical Reports see [Reports].
For more information about versions of the Unicode Standard, see [Versions].
Contents
- Each TR must have contents section,
formatting should match this sample, HTML should use <ul class="toc">.
There are two or more spaces following each number, and the links
only contain the title of each section, never the number.
- Appendices or Annexes can be numbered or lettered
and must be named Appendix or Annex
- Check each link in the table of contents
manually to make sure that it not only goes somewhere, but goes
where it should.
- These sections are required for all
reports: Summary, Status, Contents, References,
Modifications. UTS and UAX require a Conformance section.
This technical report starts with a discussion of the mathematics character
repertoire incorporating the relevant block descriptions of the Unicode....
[ TR SPECIFIC CONTENTS ELIDED]
This is a sample for a subsection, and exists primarily so that the table of contents can link to here.
Here is a sample reference to a subsection: See Section 1.1,
A Sample Subsection. Some reports use the
convention: See Section 1.1, A Sample
Subsection, but this should be phased out. The former is easier to
cut&paste from the table of contents and works more easily with moving
text between UTRs and UAXs or the book.
This section contains an item-by-item checklist of critical things to watch
for in TR updates. In this section, instructions are not marked in blue.
- Top Part
- Make sure that there is a stylesheet link:
- <link rel="stylesheet" type="text/css"
href="http://www.unicode.org/reports/reports.css">
- Set the charset to UTF-8 (In Frontpage, right-click>page
properties>language>HTML encoding.
- Above the title, make sure that the status is properly reflected
(draft, proposed draft, proposed update, etc) in
red.
- Make sure that in the HTML source, the title of any UAX is
in Title Case. The <h1> style transforms this to UPPERCASE for
the online version. In the title of a UAX, use <span
class="nocap"> for any word that should not be titlecased
when the UAX is printed in the book, such as "of" or "for".
- Verify that the link from "Technical Reports" in the navigation bar points to the TR
directory, not to a specific version.
- For UAXs and UTSs, update the version number
in the header table. The version number for a draft is the
targeted version number, followed by "(draft)",
e.g. 4.1.0 (draft)
- The version number of a UAX follows the conventions for the
Unicode Standard - for consistency all three fields should be
shown.
- The version number of a UTS should show two fields, a third
field should be used only for minuscule, yet required updates,
or for more complex standards. (UTS #10 may have 3 fields.)
- Update the author list if this has changed.
Also check author e-mail addresses for changes.
- Update the revision number. (Revision numbers
are integers and must match the
part of the filename after the '-'.)
- Check the links in the header table to make sure that Latest
Version points at the directory of the TR and This Version
points at the file itself, and Previous Version points at the
HTML file of the previous approved version.
- Check the date in the header table.
- Verify that the Status section reflects the new status
(proposed draft, proposed update, etc) and has the proper boiler plate
paragraph to go with that status.
- Have one line in the Contents for each section (<h2>) and
subsection (<h3>). These are to be linked to the
section/subsection. Check the format of the contents section.
- Changing Status
- If the update is to Proposed Update, go through the checklist
in Section 4, Creating a Proposed
Update.
- If the update is from Proposed to another category, remove
the word "Proposed" from the heading. Check that the page
title is "UTR", "UAX" or "UTS" in page properties, the title
needs to be checked and updated there as well. In the HTML source, this
is the information in <title>. The
page title never changes, unless a TR gets retitled or put on a
different track (e.g. becomes a UTS or UAX).
- If the update is a new TR, then ask Julie to
update main TR index page so
that the new number is reflected in the left navigation bar. (Julie
needs to know about any status change to the main TR page.If it changes status at all, Julie needs to update. E.g.
proposed to accepted, etc.)
- Body
- Each section, subsection, etc. should have an anchor (aka bookmark)
that will be linked from the table of contents. Use short, descriptive
phrases for the anchor, without reference to the number of the
section. Try not to change the anchors from version to version. Check
section numbering to make sure it matches the contents.
- Check all table formats: no table must be set to 100% wide, nor may
it use fixed pixel widths or it will not display/print correctly
- Verify that all images can be viewed. (UAXs have conditional
images, using a larger size for the printed version - the latter
have the same names, but instead of residing in the "images"
directory they reside in the "print-images" directory).
- You can use the following style of HTML for images of the
representative glyphs in the Standard, such as
or 
:
<img alt="03E2"
src="http://www.unicode.org/cgi-bin/refglyph?24-03E2"
style="vertical-align:middle">
(Note: The integer "24" refers to the point size of
the representative glyph, but at this time, only 24-point glyphs are
supported. "03E2" is the Unicode character hex value.)
- Where possible, don't use typewriter style:
- Only use a single space after the end of a sentence.
-
Use real punctuation instead of the ASCII fallbacks if possible.
For example:
Table 1 Punctuation and ASCII
Fallback
| Publishing |
ASCII |
| questions—and answers—about |
questions--and answers--about |
| “phthisic” |
"phthisic" |
| ‘fish’ |
'fish', `fish' |
| can’t |
can't |
-
UAXs use two style sheets, depending on whether they are
formatted for the book or for online viewing. These
style sheets allow for conditional display of text and
images, different display of titles and section
headings, as well as an extra X in all section numbers
when the UAX is printed. A full description of these
extra styles would make this document nearly unreadable
- the best way to edit UAXs is to check for the use of
styles in existing text of the same type.
- Citations
- When citing character names use UPPERCASE in your source file
together with the predefined style "name" for the character
name part only, as in U+0020 <span
class="name">SPACE</span>. This will show as:
"U+0020
SPACE"
but paste as "U+0020 SPACE", whereas using smallcaps would have pasted as
"U+0020 space"
- When referring to character classes, e.g. to class
CL,
make the name of the character class a link to its definition, using the predefined style
"charclass" as in this example:
<a class="charclass" href="#CL">CL</a>.
The predefined style is less obtrusive than the regular link style and
consistent use will let character classes stand out.
- Use "charclass" also for terms from an in-document glossary
- Add the appropriate References (and remove ones that are not
referenced). The standard style is: "For more information, see
Unicode
Frequently Asked Questions [FAQ]." The
(optional) link on the long title is a direct link, the link on
the abbreviation goes to the references. The entry in the
references should be specific at the document level (e.g.
a citation of Unicode Standard Annex #9:
“Bidirectional Algorithm”
should cite a specific reference entry such as [Bidi] or [UAX9], not
simply [Reports]).
- When editing a UAX, note that all references for UAXs are
maintained centrally in Unicode Standard Annex #41:
“Common References for Unicode Standard Annexes”
. In the text, the citation will still look like , e,g, [Bidi]
but will point to ../tr41/tr41-1.html#Bidi instead of #Bidi as
in a UTR or UTS. Note that the link is versioned. For
5.0, the link goes to tr41-1.html, for 5.1 it will go to
tr41-2.html, etc.
- When citing sections of a report use this style: See Section
3, Conformance, (phase out this style: See
Section 3, Conformance)
- When citing sections of another standard use this style: ...
as further described in Section 3.2, Conformance Requirements,
in [Unicode]. Usually, when the section
is in the Unicode Standard, do not provide a link to the
section.
- When citing UTS or UAXes use this style: ... in Unicode
Technical Standard #30, “Character
Foldings” [Foldings], in
other words, spell out the type and put the name inside curly
quotes. The link under the long name is optional.
- When editing a UAX, make sure to use the special styles that
add the "X" to section numbers, as in the following HTML
fragment:
see <span class="section">Section </span><span class="secno">8,</span>
<a href="#Customization"><i>Customization</i></a>
which would look like this:
see Section 8,
Customization
(online)
see Section X8,
Customization
(book)
- Tables
-
To get a table with no border, set the style to noborder, as in:
<table class="noborder">.
The same for a cell with no border. For large numbers of cells, use the shorter alias
nb to cut down on the size
of the HTML source file.
-
For a table that is as wide as the available margins allow, set the style to
wide, or nbwide if
the table also is to have no border. DO NOT USE
width="100%"
-
Tables, other than purely incidental, should be centered where possible and have a
caption. Use the HTML <caption> element inside <table>.
-
Table captions and column headers should use
titlecase.
-
Tables that contain code can use
class="syntax".
To set a class in FrontPage, select the table, right-click, table
properties, Style..., class
x y |
the sequence consisting of x then y |
x* |
zero or more occurences of x |
- Examples can use class="example"
Examples:
[a-z | A-Z | 0-9] |
Match ASCII alphanumerics |
[a-z A-Z 0-9] |
[a-zA-Z0-9] |
[^a-z A-Z 0-9] |
Match anything but ASCII alphanumerics |
[\] \- \ ] |
Match the literal characters ], -, ',' |
- Lists can use class="values"
| Abb. |
Long Form |
| L |
Letter |
| Lu |
Uppercase Letter |
| Ll |
Lowercase Letter |
| Lt |
Titlecase Letter |
| Lm |
Modifier Letter |
-
Sometimes a table with just a few horizontal lines, instead of
the full grid works best. The example shows such a table (table
class="gray"),
together with a table caption in the caption style:
Table 2 An Alternate Table Format
| Header Row |
Use th class="grayfirst" |
| all other rows |
use td
class="graymiddle" |
| last row in table |
use td
class="graylast" |
- End Part
- Verify that the References and Modifications sections
exist and are populated. The Acknowledgements section is
optional.
- Verify that for a UAX the section headers for the sections
at the end use the "nonumber" style
- Verify that certain tables and their cells both have style set to
"noborder" (or "nb" or "nbwide"). These include the
References and Modifications
sections at the end.
- For all UAXs, except UAX#41, the references section consists
of this text "For references for this annex, see Unicode Standard Annex #41, “Common
References for Unicode Standard Annexes.”"
- For the Modifications section, set the Modifications number to the new revision number and list the
modifications in the section at the end.
-
For UAXs, the text in the modifications section is conditional, as follows:
<h2 class="nonumber"><a name="Modifications">Modifications</a></h2>
<!-- BOOK ONLY -->
<div class="book-only">
<p>For details of the change history, see the online copy of
this annex at http://www.unicode.org/reports/tr9/.</p>
</div>
<!-- START WEB ONLY -->
<div class="web-only">
<p>The following summarizes modifications from previous revisions
of this annex.</p>
-
The following summarizes modifications from previous revisions of this annex.
- Validity
- Check that the TR file validates with the
W3C
HTML validator and CSS validator (accessible from the HTML
validation results page).
- Then run Checking
Bookmarks for Validity. That will verify that all links in
the body of the report, both internal and external, are valid.
(Note: it has a couple of bugs related to some
old-style local unicode.org links such as "unicode/unicode".)
- Then run the W3C
HTML link checker.
All UTSs need a section that describes
conformance to that standard. All UAXs need a section that explains the
implications of conforming to the Unicode Standard in the context of
conforming to the material in the given UAX. UTRs are informative, as
defined in the status section. They do not need a section on
conformance, as that would duplicate the information in the status
section.
Note: choose one of the next two paragraphs
in case of not required / required, and substitute appropriate text in
[].
| required |
Unicode-conformant implementation that implement this
specification must do so as described in the following clause. |
| not required |
There are many different ways to
[break lines of text], and the Unicode Standard does not
restrict the ways in which implementations can do this. However,
any Unicode-conformant implementation that purports to implement
this specification must do so as described in the following
clause. Implementations are free to deviate from this, as long
as they do not purport to conform to this specification. |
A conformance clause contains one of more
clauses, modeled on the following. Note: some algorithms, notably
Normalization, are not 'default' algorithms, as they contain no options,
customization, overrides or tailoring etc.
| C1 |
An implementation that claims conformance
to the default [Unicode Line Break
Algorithm] shall produce the same results as the
algorithm published in this specification.
- As specified in Section 3.2 of [Unicode], Unicode specifications are generally
described as an algorithm or process, producing a result
from a given input. However, these are simply logical
specifications; particular implementations can change or
optimize the internal processing as long as they provide the
same results from the same input.
|
| C2 |
This specification defines default
behavior, which is to be used in the absence of tailoring
for particular languages and environments.
- Where a particular environment requires tailoring, such
modifications to this specification can be done without
affecting conformance.
|
| C3 |
If tailoring is used by an implementation that
claims conformance to the default [Unicode Line Break Algorithm],
the existence of such tailoring must be documented.
- This does not require that the tailoring be described in a
reproducible manner; for example, a statement 'tailored to
language X' is sufficient.
|
| C4 |
Conformance to this standard requires
conformance to the Unicode Standard, version x.x.x or later.
Note: this is optional if a standard does
not need conformance to Unicode. Usually though, the base version is at
least 2.0.0. If a standard requires Normalization, the base version
should be set to 3.0.0 or a later version. If a standard refers to
specific code points, then the base version is the first version at
which these code points are assigned. |
At times, this specification recommends best practice. These
recommendations are not normative and conformance with this specification does
not depend on their realization. These recommendations contain the expression
"We recommend ...", "This specification recommends ...", or some similar
wording.
4 Creating a Proposed Update (or
Other Draft)
Several steps are needed when an approved Report, Standard or UAX is to
be updated. These rules apply for formally approved Proposed Updates.
There are interim drafts, such as non-public internal drafts
that go in front of the UTC or the editorial committee. The latter need to be specially
marked, particularly when they have been formatted (e.g. status section) as
they would look after their approval. However, their
file naming and numbering is different. These differences are pointed out
below in [ ].
- Changes to the Header and Status
- For each public draft, make new copy with new revision number. If old is trXX-y.html, new is
(where z = y+1): trXX-z.html.
[For an internal draft use trXX-zdn.html,
where n indicates the revision level of the particular internal
draft and z is the revision number of the document for which this is a
draft.] - put "Proposed Update"
or other draft status designator (in red) above/in front of the title
[for internal drafts add 'non-public' or 'internal']
- For UTSs and
standards:
- set the version to the new version. For major
changes increment the major version field, for minor
updates increment the minor version field. The third version
field (update version) should rarely be used for UTSs. Follow
the version by "(draft)" in red.
For UAXs:
- set
the version to the next version of the Unicode Stdandard e.g. => "4.1.0
(draft)".
[For an internal draft, use zdn as the version and optionally
add the purpose of the draft in the version field, e.g. "4.1.0d5
(draft 5 for UTC review and approval as proposed update)"] - Set the date
to the modification date of the file
- move "this version contents" to previous version box, update this
version link and text
[Since internal drafts are not maintained on the server, update these fields
the way they would be for the next public draft.] - increment the revision number
for each public draft.
- use status section for proposed update from the template.
[Internal drafts usually use the future status section, so that reviewers
can see what the approved draft or final version would look like]
- Body of the Report
- Mark significant changes with the 'changed' style,
either by adding into the
HTML source, or by using the little yellow highlighter tool in FrontPage and
later doing a global replace of into Unlike the
yellow highlights, the changed style uses a dashed line that shows up in
printed review copies.
- Alternatively, use the drop-down list in FrontPage and apply
the "changedspan" style or the
"remvovedspan" style.
- When a draft becomes a final publication, simply reverse the steps:
replace all instances of by. After that, select the whole document,
or a section covering the changes, and turn off background colors, i.e. "automatic" setting in the highlighter tool.
That's a quick way to make the changes w/o having to worry about start and
end tags for each <span>.
- In the text, make sure to follow the style guidelines in
Appendix 1, House Style.
- References
Section
- There should now be a References section everywhere, but if there is no References section, add one. Easiest is to copy from the
template (that way you get the anchor (bookmark) and table) and delete the
rows you don't need.
- Add any references you need. There is a bookmark on the part
of the reference inside the
brackets in the first column. That is, the HTML code on "[CharMod]" is
"[<a name="CharMod">CharMod</a>]".
- In the second column, you will structure it like the template. There is
a <br> (shift-ENTER) between the lines.
- Modifications
Section
- If there is no Modifications section, add one. Easiest is to copy from
the template (that way you get the anchor (bookmark) and table) and modify
to suit.
- If there is a Modifications section, add new row at top. Add
revision number.
- Describe the modifications in reasonable and appropriate detail.
- Cleanup
- Modify the copyright to be "Copyright © XXXX-200n Unicode, Inc. All
Rights Reserved." XXXX is whatever the starting date was, 200n is the
current year or anticipated year of published version.
- Fix Bookmarks. These should have no spaces in them. To do this in
FrontPage
- Open Bookmarks...
- If this is not in your tool bar, you can put it there with Tools
> Customize
- Select first item that contains spaces
- Click Goto
- Replace spaces by "_"
- Click OK
- Repeat until no more bookmarks have spaces.
- Verification and Posting
- post draft on the site, in the right directory.
- open http://validator.w3.org/ and validate the draft
- HTML validation (can be run with file on your machine)
- CSS validation
- Link Checking
- fix any validation errors
(All three validators/checkers should pass before you release the draft)
- notify
Magda so she can sanity check (by sending notice to book list
that draft is ready for 'verification')
- after all changes required for verification, notify Julie to add link to
the main Reports page, see item 7.
- If this is a Draft, Proposed Draft or Approved, then also
copy the contents over index.html
- notify Rick if a proposed Public Review Item.
- Updates on the Main Reports Page
- For a new Proposed Draft, or change to Draft or
approved use:
(Status: Proposed Draft)
(Status: Draft)
or no status designation as appropriate
- For a Proposed Update use
(See also <Proposed Update>)
with the link to the file containing the update.
- If a report changes tracks from UTR to UTS or UTR to UAX do the following:
List the title of the report in both the UTR and UTS/UAX section.
Add in the UTR section:
(See also <Proposed Update> to UTS)
Add in the UTS section (or UAX as appropriate):
(Status: Proposed Update from UTR)
5. Versioning of Images, Data files, DTDs, and Style sheets
[TBD flesh out]
5.1 Images
Images should not be updated. If other than 'invisible' change are made
to an image, it should be saved with a new name, and the new version(s) of
the report.
5.2 Data files
Data files should have a version number, e.g. MathClass-6.txt.
5.3 DTDs
DTDs must be versioned, with a -nn in the file name, as in
SampleDTD-nn.dtd.
5.4 Style sheets
The style sheet reports.css will not be revised incompatibly. If
incompatible changes are needed, a new file will be created (reports2.css)
and all newly published versions of TRs will use the new stylesheet.
UAXs use a special set of style sheets.
5.5 Reports
Some reports may be versioned by creating a version directory under the
tr-nn folder, as in
trnn/
trnn-1/
trnn-2/
trnn-3/
trnn-4/
in each folder, the main html is then named "index.html". The links in
the header for previous and current version change from "trnn/trnn-yy.html"
to the form "trnn/trnn-yy/".
This is a sample appendix. The following appendix, Appendix 2,
House Style gives information on style. Unlike
sections, appendixes need a colon in the numbering. Letters should be used
for appendices in UAXs so as to not clash with the letters used for
appendices in the book. Also, the use of annexes inside a UAX is deprecated.
At the moment, there are no numbered appendices or use of letters with
annexes, so its probably best to choose one of these alternatives as they
appear here.
When editing UTRs, UTSs and UAXs, it's best to follow the house style as
close as possible. This makes it easier to move or copy material. Note,
other parts of the website, such as the FAQ do *not* follow the house style.
- Do not use first and second person pronouns such as "I, you, we".
Instead rewrite using "one" or "the implementer", or without any pronoun.
- Spell out abbreviations (use "for example, that is, also known as, and
so on" rather than "e.g., i.e., aka, etc.")
- Use "because" rather than "since" unless "since" is being used
temporally.
- Strive for consistency in spelling and especially hyphenation. The
online [Glossary] is a good source if you are uncertain of our preferred style. For
example, we do not hyphenate "nonspacing", but "code point" is two words.
- Be consistent in capitalizing headers, the best is to use title case.
(Title Case).
- Avoid the use of NOTE, multilvel bulleted lists and similar devices
- Use short sections and subsections. This helps break down the text.
- In any type of technical report, number down to the third level (HTML:
H4)
- At least the two top level (section and subsection) must get entries in
the table of contents.
- Bookmarks and section numbers should remain stable between approved
versions, unless a significant change in the document removes a section, or
makes maintaining the order of sections unmanagable.
- Number rules and definitions. Use the letter D for definitions with a
distinct prefix to distinguish them from other definitions (for example PD11
is a definition in UTR#23,
Unicode Character Property
Model [PropertyModel], and LB8a is a
rule in UAX#14, Line Breaking Properties
[LineBreak].)
- Keep rule and definitions stable once in an approved version. Use
interpolated numbering, such as "LB11b", if a new rule needs to be added.
- Use of run-in headers at the beginning of the paragraph, like in the
book, can be appropriate for some style of reports, but is not required.
- As always, try to write in a direct, readable style. If sentences become
long and convoluted, try to simplify or split into two sentences.
- As far as possible, consider the challenges to readers who are not
non-native English speakers.
- Work with our editor (Julie) at an appropriate point in the editing
cycle to get her input in copy-editing the text for style, consistency and
readability.
- References is a required section. It should
not be numbered. (For UAXs use the "nonumber" style) Entries for FAQ, Feedback, Glossary,
Reports,
Unicode, and Versions are required entries.
- Check HTML: References is a table and should have cell and
table styles both set to "noborder" and have ample cell spacing
(e.g. 12).
Please see UAX#41 for the best available references. For UAXs,
reference them directly in the correct version (!) of UAX#41. For UTRs
and UTSs do not reference UAX#41, but copy these to the
table of references in the references section of the respective document
as needed.
- This is a required section - it should not be
numbered, make sure it contains a list of the latest modifications.
Make sure that it has a bookmark that is linked from the table of
contents. Revisions that are superseded drafts can be coalesced in
this list, by showing only the modifications between approved
versions.
The following summarizes modifications from the previous revision of this
document.
Revision 3:
- Fixed several typos.
- New header.
Revision 2:
- Rewrite and reorganization of the text as part of the publication of
the Unicode Standard, Version 3.0.
Revision 1:
- The copyright is a required section. Check format,
boilerplate and copyright date (if more than one year is given, the last
one should be the current year.)
Copyright © 2001-2007
Unicode, Inc. All Rights Reserved. The Unicode Consortium makes no expressed
or implied warranty of any kind, and assumes no liability for errors or
omissions. No liability is assumed for incidental and consequential damages in
connection with or arising out of the use of the information or programs
contained or accompanying this technical report. The Unicode
Terms of Use apply.
Unicode and the Unicode logo are trademarks of Unicode,
Inc., and are registered in some jurisdictions.
![[Unicode]](http://www.unicode.org/webscripts/logo60s2.gif){kind=small}
Technical
Reports