[Unicode]  Technical Reports
 

Checklist for approving UTRs, UTSs and UAXs for posting

Including instructions for creating and reviewing drafts

last modified: 2010-03-19 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.

  1. 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)
  2. Make sure that Unicode Standard Annexes use UAX and Unicode Technical Standards use UTS instead of UTR
  3. Check overall TR format. The Bar should look like the above. The words "Technical Reports" should link to the main reports page

  4. 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.)

  5. Check status designation (showing on of Draft or Proposed Draft, Proposed Update in red, or nothing) in the title.

  6. 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

  1. 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):

  2. The following shows the header format for the three types of documents.

8a. In all cases, if the document does not already contain the Latest Proposed Update line, then it must be added, immediately above the Revision line.

8b. 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. The file "proposed.html" consists of a copy of either the latest public draft of a proposed update or the stub that says there is no proposed update at this time. The stub is located here: http://www.unicode.org/reports/proposed.html

Version 6.0.0 (draft)
Authors Ken Whistler (ken@example.com) (not updated every time)
Date 2002-05-08 (always use ISO format)
This Version http://www.unicode.org/reports/tr14/tr14-16.html
(the number should match the tracking number, check that the link actually goes there)
Previous Version http://www.unicode.org/reports/tr14/tr14-15.html
((the number should match the tracking number, check that the link actually goes there)
Latest Version http://www.unicode.org/reports/tr14/ (check link)
Latest Proposed Update http://www.unicode.org/reports/tr14/proposed.html (check link)
Revision 5 (must match the file name of "This Version" and must link to Modifications section below)

8c. 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.)

Version 1.0
Authors Mark Davis (mark@example.com) (not updated every time)
Date 2002-05-08 (always use ISO format)
This Version http://www.unicode.org/reports/tr18/tr18-5.html
(also check the link; the number after the - is the same as the revision number)
Previous Version http://www.unicode.org/reports/tr18/tr18-4.html
(also check link; the number after the - is the same as the most recent approved version)
Latest Version http://www.unicode.org/reports/tr18/ (check link)
Latest Proposed Update http://www.unicode.org/reports/tr18/proposed.html (check link)
Revision 5  (must match the file name of "This Version" and must link to Modifications section below)

8d. UTRs only have a single revision number without dots.

Authors Barbara Beeton (bnb@example.com), Murray Sargent III (murrays@example.com)
(not updated every time, not all authors need to have e-mail)
Date 2002-05-08 (always use ISO format)
This Version http://www.unicode.org/reports/tr25/tr25-5.html
(also check the link; it should be the same number)
Previous Version http://www.unicode.org/reports/tr25/tr25-4.html
(also check link; it should be the previous number)
Latest Version http://www.unicode.org/reports/tr25/ (check link)
Latest Proposed Update http://www.unicode.org/reports/tr25/proposed.html (check link)
Revision 5 (must match the file name of "This Version" and must link to Modifications section below)

  1. The following are optional fields for standards that implement DTDs. They are inserted above "Revision".

Namespace http://www.unicode.org/cldr/
DTDs http://www.unicode.org/cldr/dtd/1.1/ldml.dtd
http://www.unicode.org/cldr/dtd/1.1/ldmlSupplemental.dtd

  1. The following ISBN row is only used for UTRs and UTSes. It goes after the "Revision" row of the header. Only released versions of UTSs and UTRs will have ISBN numbers. The actual number must not be filled-in until final publication. For proposed updates to UTSs and UTRs, delete the previous version ISBN number (if any), and replace it with the "NNNNNNNNN" placeholder, so it is clear that such unapproved, review documents do not have an ISBN number.

ISBN NNNNNNNNN

  1. Some TRs are kept in a SVN project. The latest working draft of those TRs are visible through a view in the draft directory, which follows the URL template: http://www.unicode.org/draft/reports/trXX/trXX.html Working drafts visible this way are not considered public documents. They are only for editorial committee and/or UTC review as working drafts. The draft URLs should never be published as part of the public header version fields of a UAX, UTS, or UTR.

Summary

  1. All reports must have a brief summary.
  2. 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

  1. 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. NOTE: in most UAXes, the approved and draft status sections are usually already present, and one or the other is commented out. When doing updates, you should check this before writing over the Status paragraph: you may often be able to uncomment the "other" one.

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. Often, this paragraph is also put into a "changed" style to make it stand out.
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 online 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 of the Unicode Standard of which it forms a part.

 

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].

!!WARNING!! The above links to Feedback, Unicode, Reports, Versions, Errata need to be set to a specific version of UAX #41 in the final documents. The links will be bad, and will need to be updated during document review to point to the relevant revision of UAX #41 for that particular release. The sentence on Errata is new, and all updates for UAXs need to check that it gets added.

For UTRs and UTSes, use this paragraph, which contains the minimal required references that must be present in the References section of the TR:

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

  1. 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.
  2. Appendices or Annexes can be numbered or lettered and must be named Appendix or Annex
  3. Check each link in the table of contents manually to make sure that it not only goes somewhere, but goes where it should.
  1. These sections are required for all reports: Summary, Status, Contents, References, Modifications. UTS and UAX require a Conformance section.
  2. When writing a new UTR/UAX/UTS that contains references to other documents, see the section below on Style Guidelines for cross-references. The guide should also be consulted when you add or change references.
  3. When making an update, check that the Modifications section has the right format according to template above: an anchor labeled "#Modifications", and the Revision number link in the document header points to it. E.g. in the header:
    <td><a href="#Modifications">24</a></td>
    The section for modifications begins:
    <h2><a name="Modifications">Modifications</a></h2>

1 Overview 

This technical report starts with a discussion of the mathematics character repertoire incorporating the relevant block descriptions of the Unicode....  [ TR SPECIFIC CONTENTS ELIDED]

1.1 A Sample Subsection

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.

2 The Checklist

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.

  1. Top Part
    1. Make sure that there is a stylesheet link:
      • <link rel="stylesheet" type="text/css" href="http://www.unicode.org/reports/reports.css">
    2. Set the charset to UTF-8 (In Frontpage, right-click>page properties>language>HTML encoding.
    3. Above the title, make sure that the status is properly reflected (draft, proposed draft, proposed update, etc) in red.
    4. 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".
    5. Verify that the link from "Technical Reports" in the navigation bar points to the TR directory, not to a specific version.
    6. 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)
    7. The version number of a UAX follows the conventions for the Unicode Standard - for consistency all three fields should be shown.
    8. 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.)
    9. Update the author list if this has changed. Also check author e-mail addresses for changes.
    10. Update the revision number. (Revision numbers are integers and must match the part of the filename after the '-'.)
    11. 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.
    12. Check the date in the header table.
    13. 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.
    14. 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.
  2. Changing Status
    1. If the update is to Proposed Update, go through the checklist in Section 4, Creating a Proposed Update.
    2. 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).
    3. 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.)
  3. Body
    1. 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.
    2. 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.
    3. 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).
    4. You can use the following style of HTML for images of the representative glyphs in the Standard, such as 03E2 or 3080:
                   <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.)
    5. Where possible, don't use typewriter style:
      1. Only use a single space after the end of a sentence.

      2. 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
    6. 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.
    7. Make sure that all rules and definitions have anchors (bookmarks) on them. See for example UAXes #9  and #14.
  4. Citations For detailed discussion of citation styles, see the page Style Guidelines for Cross References. In the list below, sections with yellow background are actual sample references for clarity.
    1. 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"
    2. 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.
    3. Use "charclass" also for terms from an in-document glossary
    4. 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]). For example a full citation would be this text (without the yellow): See Unicode Standard Annex #9: “Bidirectional Algorithm” [UAX9].
    5. 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.1, the link went to tr41-2.html, for 5.2 it went to tr41-5.html, etc.
    6. When citing sections of a report use this style: See Section 3, Conformance, (phase out this style: See Section 3, Conformance) See the style guideline.
    7. 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.
    8. 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.
    9. 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)

  5. Tables

    1. 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.

    2. 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%"

    3. Tables, other than purely incidental, should be centered where possible and have a caption.

    4. Make sure every captioned table (and every captioned figure) has an anchor (bookmark) on it for unique identification. Bookmarks based on the caption, rather than table (or figure) numbering are preferred, for referential stability. Where tables (or figures) are referenced in the text, except in paragraphs immediately introducing the table, make a link to the table's anchor.

    5. Table captions and column headers should use titlecase.

    6. 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
    7. 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 ], -, ','
    8. Lists can use class="values"
      Abb. Long Form
      L Letter
      Lu Uppercase Letter
      Ll Lowercase Letter
      Lt Titlecase Letter
      Lm Modifier Letter

    9. 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"
  6. End Part
    1. Verify that the References and Modifications sections exist and are populated. The Acknowledgements section is optional.
    2. Verify that for a UAX the section headers for the sections at the end use the "nonumber" style
    3. 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.
    4. 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.”"
    5. For the Modifications section, set the Modifications number to the new revision number and list the modifications in the section at the end.
    6. 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>

    7. The following summarizes modifications from previous revisions of this annex.
  7. Validity
    1. Check that the TR file validates with the W3C HTML validator and CSS validator (accessible from the HTML validation results page).
    2. 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".)
    3. Then run the W3C HTML link checker.

3 Conformance

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, Conformance Requirements in [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 [ ].

  1. Changes to the Header and Status
    1. 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.]
    2. put "Proposed Update" or other draft status designator (in red) above/in front of the title [for internal drafts add 'non-public' or 'internal']
    3. 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)"]
    4. Set the date to the modification date of the file
    5. 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.]
    6. increment the revision number for each public draft.
    7. 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]
  2. Body of the Report
    1. Mark significant changes with the 'changed' style, either by adding class="changed" into the HTML source, or by using the little yellow highlighter tool in FrontPage and later doing a global replace of  style="background-color: #FFFF00" into class="changed". Unlike the yellow highlights, the changed style uses a dashed line that shows up in printed review copies.
    2. Alternatively, use the drop-down list in FrontPage and apply the "changedspan" style or the "remvovedspan" style.
    3. When a draft becomes a final publication, simply reverse the steps: replace all instances of   class="changed" by style="background-color: #FFFF00". 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>.
    4. In the text, make sure to follow the style guidelines in Appendix 1, House Style.
  3. References Section
    1. 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.
    2. 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>]".
    3. In the second column, you will structure it like the template. There is a <br> (shift-ENTER) between the lines.
  4. Modifications Section
    1. 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.
    2. If there is a Modifications section, add new row at top. Add revision number.
    3. Describe the modifications in reasonable and appropriate detail.
  5. Cleanup
    1. 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.
    2. Fix Bookmarks. These should have no spaces in them. To do this in FrontPage
      1. Open Bookmarks...
        1. If this is not in your tool bar, you can put it there with Tools > Customize
      2. Select first item that contains spaces
      3. Click Goto
      4. Replace spaces by "_"
      5. Click OK
      6. Repeat until no more bookmarks have spaces.
  6. Verification and Posting
    1. post draft on the site, in the right directory.
    2. open http://validator.w3.org/ and validate the draft
      • HTML validation (can be run with file on your machine)
      • CSS validation
      • Link Checking
    3. fix any validation errors (All three validators/checkers should pass before you release the draft)
    4. notify Magda so she can sanity check (by sending notice to book list that draft is ready for 'verification')
    5. after all changes required for verification, notify Julie to add link to the main Reports page, see item 7.
    6. If this is a Draft, Proposed Draft or Approved, then also copy the contents over index.html and proposed.html (do NOT copy over index.html for any Proposed Draft or Proposed Update: index.html is only for approved reports, or for drafts prior to the issuance of the first approved version.)
    7. If this is an Approved TR and there is no Proposed Draft or Proposed Update any more, then copy http://www.unicode.org/reports/proposed.html to proposed.html in the directory of the TR. (When there is a Proposed Draft or Proposed Update, then proposed.html is a copy of it.)
    8. notify Rick if a proposed Public Review Item.
  7. Updates on the Main Reports Page
    1. For a new Proposed Draft, or change to Draft or approved use:
        (Status: Proposed Draft)
        (Status: Draft)
      or no status designation as appropriate
    2. For a Proposed Update use
        (See also <Proposed Update>)
      with the link to the file containing the update.
    3. 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)
    4. For Proposed Updates of UAXes, see and update the UAX Proposed Updates page.

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.

UAXes must have both web and print versions of their images. Print versions are suitable for printing at 300dpi.

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/".

Appendix 1: Sample Appendix

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.

Appendix 2:  House Style

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.

Style Guidelines for Cross References

There is a page of style guidelines for cross references between book text and UAXes, for example, how to refer to the Unicode Standard (the book) from within a UAX: http://www.unicode.org/reports/style_guidelines.html

References

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.

Modifications

The following summarizes modifications from the previous revision of this document.

Revision 3: 

Revision 2: 

Revision 1:

Copyright © 2001-2010 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.