ISO/IEC JTC1/SC18/WG8 **N932**

Title:

Recommendations for revision of ISO/IEC TR 9573

Source:

Charles F. Goldfarb

Project:

1.18.15.1

Project editor:

Charles F. Goldfarb

Status of document:

Approved WG8 document

Requested action:

For information

Date

89-08-30

Distribution:

WG8 and liaisons

Introduction

The following items were approved by the developers of ISO 8879 in the
course of reviewing comments on that standard. The items address
portions of ISO 8879 that the developers do not intend to include in any
future revised edition if one is published. Instead, the developers have
recommended that the material be moved to ISO/IEC TR 9573.

It is expected that a revised edition of ISO/IEC TR 9573 will be
published as a multi-part technical report. The items contained in this
document should be considered in the preparation of that revision in
accordance with their designated codes (explained below).

Items are listed in order by clause number in ISO 8879. General comments
precede those relating to specific clauses. Each item is preceded by a
two-letter code indicating the status of the item and the type of change
involved. If the source of the item is a WG8 document, the document
number and item number within that document, if any, are given in
parentheses. (The attachments to WG8 N680 are N680A, N680B, and N680C.)

The status codes are:

A

Accepted as editing instructions for first draft of revision.

F

Accepted for further study in preparation of revision.

The types of change code are:

E

Editorial: correction of typographical errors, restatement of unclear
text, and changes made for consistency with ISO 8879.

General Editorial

AE

Incorporate the text of the following annexes (which will not be
included in any future revision of ISO 8879) under the indicated topics,
identifying it as a revision of informative text that appears in ISO
8879.

Annex B: Tutorial on basic SGML concepts

Annex C: Tutorial on additional SGML concepts

Annex D.3: Variant concrete syntaxes, including multicode concrete
syntaxes

Annex D (except D.3): Public entity sets

Annex E.1: Example of document type definition

Annex E.2: Computer graphics metafile

Annex E.3: Device-independent techniques for code extension

AE

(N680B 81)

Change public identifiers on any revised public text.

AE

All references to ISO standards should change ╬-┘ before year to ╬:┘.
For example, ╬ISO 8879-1986┘ should be ╬ISO 8879:1986┘.

AE

Avoid ╬instance of an element┘. It should be ╬element┘, or ╬instance of
an element type┘ when emphasis on the type is desired.

AE (N924)

Examples of multiple-byte codes in ISO 8879 (none at present) or in
technical reports should be modified to follow the recommendation in WG8
N924.

AE

(N680B 2)

Use italicized phrases consistently.

FE 13

(N759 12, N790 2)

Clarify relationship between document character set and syntax-reference
character set. In particular, that concrete syntax is defined in terms
of characters, not bit combinations. (Contributions invited: examples
and discussion are needed.)

Annex B

FE B (N680B 43╙51)

Make editorial changes.

Annex C

FE C

(N680B 52╙58)

Make editorial changes.

AE C.1.1.2

(N680C 10)

Correct element declaration syntax.

AE C.1.4 (N680C 6)

In \<joblist\> example, change ╬Lynn┘ to: Lynne

FE C.1.4 (N673 4)

Correct example and make editorial changes.

FE C.3.1

Correct the example.

Annex D

FE D

(N680B 59╙60)

Make editorial changes.

AE D.4

Delete the ╬=┘ flag from all entity declaration comments in all public
entity sets.

FE D.4 (N680C 12)

The public entity sets should use the Glyph ID from the AFII
International Register in the comments as a means of identifying the
characteristic glyph.

FE D.4

Change MathSci reference to ╬Appendix D, February 1988┘ and/or Smith and
Stutely and/or AFII register (and/or include AFII register pages in
Technical Report).

FE D.4

(N680B 3╙5 12 13 61╙67 80╙81)

Make changes to public entity sets specified in N1421 1.3 with
corrections and other changes as appropriate.

Annex E

Annex E.1

AE E.1 (N680C 8)

Delete ╬address\|┘ from model group for titlep. (It is in %s.zz.)

AE E.1 (N680C 3)

The element declaration for %p.rf.ph should have O for end-tag
minimization.

AE E.1 (N680C 2)

Inline figures should be distinguished from floating figures in order to
insure proper handling of record ends. Discuss the implications.

AE E.1 (N680B 14)

Give the ╬note┘ element a more flexible structure, as follows:

In the entity declaration for s.p.d delete: \|note

In the entity declaration for ps.elem add: \|note

After the element declaration for %s.p.d add:

\<!ELEMENT note - - (p, (%s.zz;)\*) \-- Note \--\>

FE E.1

(N680B 15,

N680C 9)

Include new short references with the existing ones:

\<!ENTITY alinetg STARTTAG \"aline\" \-- Address line start-tag \--\>

\<!SHORTREF addrmap \"&#RS;B\" alinetg \-- Address line start-tag \--\>

\<!USEMAP addrmap address\>

\<!ENTITY tlinetg STARTTAG \"tline\" \-- Title line start-tag \--\>

\<!SHORTREF tlinmap \"&#RS;B\" tlinetg \-- Address title start-tag \--\>

\<!USEMAP tlinmap title \>

This map allows the TITLE and ADDRESS end-tags to be in records of their
own, rather than in the same record as the last TLINE or ALINE.

\<title\>

First line

Last line

\</title\>

FE E.1

Consider

\<H1\>Header of a clause

\<FIG ID=\....\>

\<ARTWORK \....\>

\</FIG\>

\<FIG \...\>

etc.

The way the DTD is constructed the \<FIG\>s are taken to be part of the
heading of the clause! Fix for this is:

\<!ELEMENT (h0t\| \....) O O %m.ph; -(%i.float;) \>

unless you want to make it -(fig) only, permitting FN on headings. Check
for other occurrences of this situation. Discuss the implications.

AE E.1 (N680A, N680B 70, N680C 4)

Correct the capacity calculation.

FE E.1

(N680B 68)

Redraft E.1 to reflect ╬current thinking.┘ (We have to guess what they
are thinking because they didn\'t say.)

Annex E.2

AE E.2

(N680C 5)

In third paragraph, change ╬analagous┘ to: analogous

FE E.2

(N680B 71)

Editorial change in Figure 12.

Annex E.3

FE E.3 (N790 3)

Clarify distinctions between ╬byte┘ and ╬bit combination┘ and between
╬code┘ and ╬character┘.

FE E.3 (N680B 72╙73)

Make editorial changes.

AE E.3 (N924)

Add new clause:

E.3.2 Multiple-byte Codes

In some multiple-byte codes, the order of the high and low bytes is
implementation-dependent. For this reason, the standard method of
representing such codes is in two pairs, corresponding to the high and
low bytes, respectively. Each byte is also represented as a pair of
numbers, corresponding to the high and low nibbles.

> When multiple-byte codes are used, it is recommended that a character
> number in a markup declaration be accompanied by a comment showing the
> equivalent nibble-by-nibble representation, as in the following
> examples:
>
> \-- 00/00 00/00 \-- 0
>
> \-- 00/00 00/15 \-- 15
>
> \-- 00/00 01/00 \-- 16
>
> \-- 00/00 15/15 \-- 255
>
> \-- 00/01 00/00 \-- 256
>
> \-- 15/15 15/15 \-- 65535