Network Working Group F. Yergeau
Internet Draft G. Nicol
<draft-ietf-html-i18n-03.txt> G. Adams
Expires 18 August 1996 M. Duerst
13 February 1996
Internationalization of the Hypertext Markup Language
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this document is unlimited. Please send comments to
the HTML working group (HTML-WG) of the Internet Engineering Task
Force (IETF) at <html-wg@w3.org>. Subscription address is <html-wg-
request@w3.org>. Discussions of the group are archived at URL:
http://www.acl.lanl.gov/HTML_WG/archives.html.
Abstract
The Hypertext Markup Language (HTML) is a simple markup language used
to create hypertext documents that are platform independent. Ini-
tially, the application of HTML on the World Wide Web was seriously
restricted by its reliance on the ISO-8859-1 coded character set,
which is appropriate only for Western European languages. Despite
this restriction, HTML has been widely used with other languages,
using other coded character sets or character encodings, at the
expense of interoperability.
This document is meant to address the issue of the
Expires 18 August 1996 [Page 1]
Internet Draft HTML internationalization 13 February 1996
internationalization of HTML by extending the specification of HTML
and giving additional recommendations for proper internationalisation
support. A foremost consideration is to make sure that HTML remains
a valid application of SGML, while enabling its use in all languages
of the world.
Table of contents
1. Introduction .................................................. 2
1.1. Scope ...................................................... 3
1.2. Conformance ................................................ 3
2. The document character set ..................................... 4
2.1. Reference processing model ................................. 4
2.2. The document character set ................................. 6
2.3. Undisplayable characters ................................... 7
3. The LANG attribute.............................................. 7
4. Additional entities, attributes and elements ................... 9
4.1. Full Latin-1 entity set .................................... 9
4.2. Markup for language-dependent presentation ................. 9
5. Forms ..........................................................11
5.1. DTD additions ..............................................11
5.2. Form submission ............................................12
6. Miscellaneous ..................................................13
7. HTML public text ...............................................15
7.1. HTML DTD ...................................................15
7.2. SGML declaration for HTML ..................................30
7.3. ISO Latin 1 character entity set ...........................31
Bibliography ......................................................34
Authors' Addresses ................................................36
1. Introduction
The Hypertext Markup Language (HTML) is a simple markup language used
to create hypertext documents that are platform independent. Ini-
tially, the application of HTML on the World Wide Web was seriously
restricted by its reliance on the ISO-8859-1 coded character set,
which is appropriate only for Western European languages. Despite
this restriction, HTML has been widely used with other languages,
using other coded character sets or character encodings, through var-
ious ad hoc extensions to the language [TAKADA].
This document is meant to address the issue of the internationaliza-
tion of HTML by extending the specification of HTML and giving addi-
tional recommendations for proper internationalisation support. It
is in good part based on a paper by one of the authors on multilin-
gualism on the WWW [NICOL]. A foremost consideration is to make sure
Expires 18 August 1996 [Page 2]
Internet Draft HTML internationalization 13 February 1996
that HTML remains a valid application of SGML, while enabling its use
in all languages of the world.
The specific issues addressed are the SGML document character set to
be used for HTML, the proper treatment of the charset parameter asso-
ciated with the "text/html" content type and the specification of
language tags and additional entities.
1.1 Scope
HTML has been in use by the World-Wide Web (WWW) global information
initiative since 1990. This specification extends the capabilities
of HTML (RFC 1866), primarily by removing the restriction to the
ISO-8859-1 coded character set [ISO-8859-1].
HTML is an application of ISO Standard 8879:1986, Information Pro-
cessing Text and Office Systems -- Standard Generalized Markup Lan-
guage (SGML) [ISO-8879]. The HTML Document Type Definition (DTD) is a
formal definition of the HTML syntax in terms of SGML. This specifi-
cation amends the DTD of HTML in order to make it applicable to docu-
ments encompassing a character repertoire much larger than that of
ISO-8859-1, while still remaining SGML conformant.
1.2 Conformance
This specification changes slightly the conformance requirements of
HTML documents and HTML user agents.
1.2.1 Documents
All HTML 2.0 conforming documents remain conforming with this speci-
fication. However, the extensions introduced here make valid cer-
tains documents that would not be HTML 2.0 conforming, in particular
those containing characters or character references outside of the
repertoire of ISO 8859-1, and those containing markup introduced
herein.
1.2.2. User agents
In addition to the requirements of RFC 1866, the following require-
ments are placed on HTML user agents.
To ensure interoperability and proper support for at least
ISO-8859-1 in an environment where character encoding schemes
other than ISO-8859-1 are present, user agents must correctly
interpret the charset parameter accompanying an HTML document
Expires 18 August 1996 [Page 3]
Internet Draft HTML internationalization 13 February 1996
received from the network.
Furthermore, conforming user-agents are required to at least parse
correctly all numeric character references within the range of the
Basic Multilingual Plane (BMP) of ISO 10646-1 [ISO-10646].
2. The document character set
2.1. Reference processing model
This overview explains a reference processing model used for HTML,
and in particular the SGML concept of a document character set. An
actual implementation may widely differ in its internal workings from
the model given below, but should behave as described to an outside
observer.
Because there are various widely differing encodings of text, SGML
does not directly address the question of how characters are encoded
e.g. in a file. SGML views the characters as a single set (called a
"character repertoire"), and a "code set" that assigns an integer
number (known as "character number") to each character in the reper-
toire. The document character set declaration defines what each of
the character numbers represents [GOLD90, p. 451]. In most cases, an
SGML DTD and all documents that refer to it have a single document
character set, and all markup and data characters are part of this
set.
HTML, as an application of SGML, does not directly address the ques-
tion of how characters are encoded as octets in external representa-
tions such as files. This is deferred to mechanisms external to HTML,
such as MIME as used by the HTTP protocol or by electronic mail.
For the HTTP protocol [HTTP-1.0], the way characters are encoded is
defined by the "charset" parameter [1] of the "Content-Type" field of
the header of an HTTP response. For example, to indicate that the
transmitted document is encoded in the "JIS" encoding of Japanese
[RFC1468], the header will contain the following line:
Content-Type: text/html; charset=ISO-2022-JP
_________________________
[1] The term "charset" in MIME is used to designate a
character encoding, rather than a coded character set
as the term may suggest. A character encoding is a
mapping (possibly many-to-one) of a sequence of octets
to a sequence of characters taken from one or more
character repertoires.
Expires 18 August 1996 [Page 4]
Internet Draft HTML internationalization 13 February 1996
The default charset parameter in the case of the HTTP protocol is
ISO-8859-1 (the so-called "Latin-1" for Western European characters).
The HTTP protocol also defines a mechanism for the client to specify
the character encodings it can accept. Clients and servers are
strongly requested to use these mechanisms to assure correct trans-
mission and interpretation of any document. Provisions that can be
taken to help correct interpretation, even in cases where a server or
client do not yet use these mechanisms, are described in section 6.
Similarly, if HTML documents are transferred by electronic mail, the
character encoding is defined by the "charset" parameter of the "Con-
tent-Type" MIME header line [RFC1521].
In the case any other way of transferring and storing HTML documents
are defined or become popular, it is advised that similar provisions
should be made to clearly identify the character encoding used and/or
to use a single/default encoding capable of representing the widest
range of characters used in an international context.
Whatever the external character encoding actually be, the reference
processing model translates it to a representation of the document
character set specified in Section 2.2 before processing specific to
SGML/HTML. The reference processing model can be depicted as fol-
lows:
[resource]->[decoder]->[entity ]->[ SGML ]->[application]->[display]
[manager] [parser]
^ |
| |
+----------+
The decoder is responsible for decoding the external representation
of the resource to a representation using the document character set.
The entity manager, the parser, and the application deal only with
characters of the document character set. A display-oriented part of
the application or the display machinery itself may again convert
characters represented in the document character set to some other
representation more suitable for their purpose. In any case, the
entity manager, the parser, and the application, as far as character
semantics are concerned, are using the HTML document character set
only.
An actual implementation may choose, or not, to translate the docu-
ment into some encoding of the document character set as described
above; the behaviour described by this reference processing model can
be achieved otherwise. This subject is well out of the scope of this
specification, however, and the reader is invited to consult the SGML
standard [ISO-8879] or a SGML handbook [BRYAN88] [GOLD90] [VANH90]
Expires 18 August 1996 [Page 5]
Internet Draft HTML internationalization 13 February 1996
[SQ91] for further information.
The most important consequence of this reference processing model is
that numeric character references are always resolved with respect to
the fixed document character set, and thus to the same characters,
whatever the external encoding actually used. For an example, see
Section 2.2.
2.2. The document character set
The document character set, in the SGML sense, is the Basic Multilin-
gual Plane of ISO 10646:1993 [ISO-10646], also known as UCS-2. This
is code-by-code identical with the Unicode standard [UNICODE]. The
adoption of this document character set implies a change in the SGML
declaration specified in the HTML 2.0 specification (section 9.5 of
[RFC1866]). The change amounts to removing the two BASESET specifi-
cations and their accompanying DESCSET declarations, replacing them
with the following declaration:
BASESET "ISO Registration Number 176//CHARSET
ISO/IEC 10646-1:1993 UCS-2 with implementation level 3
//ESC 2/5 2/15 4/5"
DESCSET 0 9 UNUSED
9 2 9
11 2 UNUSED
13 1 13
14 18 UNUSED
32 95 32
127 1 UNUSED
128 32 UNUSED
160 65374 160
Making UCS-2 the document character set does not create non-
conformance of any expression, construct or document that is conform-
ing to HTML 2.0. It does make conforming certain constructs that are
not admissible in HTML 2.0. One consequence is that data characters
outside the repertoire of ISO-8859-1, but within that of UCS-2 become
valid SGML characters. Another is that the upper limit of the range
of numeric character references is extended from 255 to 65533 [2] ;
thus, И is a valid reference to a "CYRILLIC CAPITAL LETTER I".
[ERCS] is a good source of information on Unicode and SGML, although
_________________________
[2] 65533 (FFFD hexadecimal) is the last valid char-
acter in UCS-2. 65534 (FFFE hexadecimal) is unassigned
and reserved as the byte-swapped version of ZERO WIDTH
NON-BREAKING SPACE for byte-sex detection purposes.
65535 (FFFF hexadecimal) is unassigned.
Expires 18 August 1996 [Page 6]
Internet Draft HTML internationalization 13 February 1996
its scope and technical content differ greatly from this specifica-
tion.
ISO 10646-1:1993 is the most encompassing character set currently
existing, and there is no other character set that could take its
place as the document character set for HTML. Also, it is expected
that with future extensions of ISO 10646, this specification may also
be extended. If nevertheless for a specific application there is a
need to use characters outside this standard, this should be done by
avoiding any conflicts with present or future versions of ISO 10646,
i.e. by assigning these characters to a private zone. Also, it should
be borne in mind that such a use will be highly unportable; in many
cases, it may be better to use inline bitmaps.
2.3. Undisplayable characters
With the document character set being the full ISO 10646 BMP, the
possibility that a character cannot be displayed due to lack of
appropriate resources (fonts) cannot be avoided. Because there are
many different things that can be done in such a case, this document
does not prescribe any specific behaviour. Depending on the implemen-
tation, this may also be handled by the underlaying display system
and not the application itself. The following considerations, how-
ever, may be of help:
- A clearly visible, but unobtrusive behaviour should be preferred.
Some documents may contain many characters that cannot be renden-
dered, and so showing an alert for each of them is not the right
thing to do.
- In case a numeric representation of the missing character is
given, its hexadecimal (not decimal) form is to be preferred,
because this form is used in character set standards [ERCS].
3. The LANG attribute
Language tags can be used to control rendering of a marked up docu-
ment in various ways: character disambiguation, in cases where the
character encoding is not sufficient to resolve to a specific glyph;
quotation marks; hyphenation; ligatures; spacing; voice synthesis;
etc. Independently of rendering issues, language markup is useful as
content markup for purposes such as classification and searching.
Since any text can logically be assigned a language, almost all HTML
elements admit the LANG attribute. The DTD reflects this. It is
also intended that any new element introduced in later versions of
HTML will admit the LANG attribute, unless there is a good reason not
to do so.
Expires 18 August 1996 [Page 7]
Internet Draft HTML internationalization 13 February 1996
The language attribute, LANG, takes as its value a language tag that
identifies a natural language spoken, written, or otherwise conveyed
by human beings for communication of information to other human
beings. Computer languages are explicitly excluded.
The syntax and registry of HTML language tags is the same as that
defined by RFC 1766 [RFC1766]. In summary, a language tag is composed
of one or more parts: A primary language tag and a possibly empty
series of subtags:
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Whitespace is not allowed within the tag and all tags are case-
insensitive. The namespace of language tags is administered by the
IANA. Example tags include:
en, en-US, en-cockney, i-cherokee, x-pig-latin
Two-letter primary-tags are reserved for ISO 639 language abbrevia-
tions [ISO-639], and three-letter primary-tags for the language
abbreviations of the "Ethnologue" [ETHNO] (the latter is in addition
to the requirements of RFC 1766). Any two-letter initial subtag is an
ISO 3166 country code [ISO-3166].
In the context of HTML, a language tag is not to be interpreted as a
single token, as per RFC 1766, but as a hierarchy. For example, a
user agent that adjusts rendering according to language should con-
sider that it has a match when a language tag in a style sheet entry
matches the initial portion of the language tag of an element. An
exact match should be preferred. This interpretation allows an ele-
ment marked up as, for instance, "en-US" to trigger styles corre-
sponding to, in order of preference, US-English ("en-US") or 'plain'
or 'international' English ("en").
NOTE -- using the language tag as a hierarchy does not
imply that all languages with a common prefix will be
understood by those fluent in one or more of those lan-
guages; it simply allows the user to request this commonal-
ity when it is true for that user.
The rendering of elements may be affected by the LANG attribute. For
any element, the value of the LANG attribute overrides the value
specified by the LANG attribute of any enclosing element and the
value (if any) of the HTTP Content-Language header. If none of these
are set, a suitable default, perhaps controlled by user preferences,
by automatic context analysis or by the user's locale, should be used
Expires 18 August 1996 [Page 8]
Internet Draft HTML internationalization 13 February 1996
to control rendering.
4. Additional entities, attributes and elements
4.1. Full Latin-1 entity set
According to the suggestion of section 14 of [RFC1866], the set of
Latin-1 entities is extended to cover the whole right part of
ISO-8859-1 (all code positions with the high-order bit set). The
names of the entities are taken from the appendices of [SGML]. A
list is provided in section 7.3 of this specification.
4.2. Markup for language-dependent presentation
For the correct presentation of text from certain languages (irre-
spective of formatting issues), some support in the form of addi-
tional entities and elements is needed. Markup is needed in some
cases to force or block joining behavior in contexts in which joining
would occur but should not or would not occur but should.
Many languages are written in horizontal lines from left to right,
while others are written from right to left. When both writing
directions are present, one talks of bidirectional text (BIDI for
short). BIDI text requires markup in special circumstances where
ambiguities as to the directionality of some characters have to be
resolved. This markup affects the ability to render BIDI text in a
semantically legible fashion. That is, without this special BIDI
markup, cases arise which would prevent *any* rendering whatsoever
that reflected the basic meaning of the text. Plain text may contain
this markup (joining or BIDI) in the form of special-purpose charac-
ters; in HTML, these are replaced by SGML markup as follows:
First, a generic container is needed to carry the LANG and DIR (see
below) attributes in cases where no other element is appropriate; the
SPAN element is introduced for that purpose.
A set of named character entities is added that allows partial sup-
port of the Unicode bidirectional algorithm [UNICODE], plus some help
with languages requiring contextual analysis for rendering:
<!ENTITY zwnj CDATA "‌"--=zero width non-joiner-->
<!ENTITY zwj CDATA "‍"--=zero width joiner-->
<!ENTITY lrm CDATA "‎"--=left-to-right mark-->
<!ENTITY rlm CDATA "‏"--=right-to-left mark-->
Next, an attribute called DIR is introduced, restricted to the values
LTR (left-to-right) and RTL (right-to-left) and admitted by most ele-
ments. On block-type elements, the DIR attribute indicates the base
Expires 18 August 1996 [Page 9]
Internet Draft HTML internationalization 13 February 1996
directionality of the text in the block; if omitted it is inherited
from the parent element. On inline elements, it makes the element
start a new embedding level (to be explained below); if omitted the
inline element does not start a new embedding level.
Lastly, a new element called BDO (BIDI override) is introduced, which
requires the DIR attribute to specify whether the override is left-
to-right or right-to-left. Its effect is to force the directionality
of all characters within it to the value of DIR, irrespective of
their intrinsic directional properties.
The zero-width joiner and non-joiner (‍ and ‌) are used to
control joining behaviour. For example, ARABIC LETTER HEH is used in
isolation to abbreviate "Hijri" (the Islamic calendrical system);
however, the initial form of the letter is desired, because the iso-
lated form of HEH looks like the digit five as employed in Arabic
script. This is obtained by following the HEH with a zero-width
joiner whose only effect is to provide context. In Persian texts,
there are cases where a letter that normally would join a subsequent
letter in a cursive connection does not. Here a zero-width non-
joiner is used.
The left-to-right and right-to-left marks (‎ and ‏) are used
to disambiguate directionality of neutral characters, e.g., if you
have a double quote sitting between an Arabic and a Latin letter,
then which direction does the quote resolve to? These characters are
like zero width spaces which have a directional property (but no
word/line break property).
Nested embeddings of contra-directional text runs is also a case
where the implicit directionality of characters is not sufficient,
requiring markup. A common need for the embedding controls is to han-
dle text that has been pasted from one bidi context to another, and
the possibility of multiply embedded pastings. Following is an exam-
ple of a case where embedding is needed, showing its effect:
Given the following latin (upper case) and arabic (lower
case) letters in backing store with the specified embed-
dings:
<SPAN DIR=LTR> AB <SPAN DIR=RTL> xy <SPAN DIR=LTR> CD
</SPAN> zw </SPAN> EF </SPAN>
One gets the following rendering (with [] showing the
directional transitions):
[ AB [ wz [ CD ] yx ] EF ]
Expires 18 August 1996 [Page 10]
Internet Draft HTML internationalization 13 February 1996
On the other hand, without this markup and with a base
direction of LTR one gets the following rendering:
[ AB [ yx ] CD [ wz ] EF ]
Notice that yx is on the left and wz on the right unlike
the above case where the embedding levels are used. With-
out the embedding markup one has at most two levels: a base
directional level and a single counterflow directional
level.
The directional override feature (<BDO>)is needed to deal with
unusual pieces of text in which directionality cannot be resolved
from context in an unambiguous fashion. For example, it can be used
to force left-to-right (or right-to-left) display of part numbers
composed of Latin letters, digits and Hebrew letters.
A few other additional elements are important to have for proper lan-
guage-dependent rendering.
Short quotations, and in particular the quotation marks surrounding
them, are typically rendered differently in different languages and
on platforms with different graphic capabilities: "a quotation in
English", `another, slightly better one', ,,a quotation in German'',
<< a quotation in French >>. The <Q> element is introduced for that
purpose.
Many languages require superscripts for proper rendering: as an exam-
ple, the French "Mlle Dupont" should have "lle" in superscript. The
<SUP> element, and its sibling <SUB>, are introduced to allow proper
markup of such text. <SUP> and <SUB> contents are restricted to
PCDATA to avoid nesting problems.
Finally, in many languages text justification is much more important
than it is in Western languages, and justifies markup. The ALIGN
attribute, admitting values of LEFT, RIGHT, CENTER and JUSTIFY, is
added to a selection of elements where it makes sense (block-like).
5. Forms
5.1. DTD additions
It is natural to expect input in any language in forms, as they pro-
vide one of the only ways of obtaining user input. While this is pri-
marily a UI issue, there are some things that should be specified at
the HTML level to guide behavior and promote interoperability.
Expires 18 August 1996 [Page 11]
Internet Draft HTML internationalization 13 February 1996
To ensure full interoperability, it is necessary for the user agent
(and the user) to have an indication of the character encoding(s)
that the server providing a form will be able to handle upon submis-
sion of the filled-in form. Such an indication is provided by the
ACCEPT-CHARSET attribute of the INPUT and TEXTAREA elements, modeled
on the HTTP Accept-Charset header (see [HTTP-1.1]), which contains a
space and/or comma delimited list of character sets acceptable to the
server. A user agent may want to somehow advise the user of the con-
tents of this attribute, or to restrict his possibility to enter
characters outside the repertoires of the listed character sets.
NOTE -- The list of character sets is to be interpreted as
an EXCLUSIVE-OR list; the server announces that it is ready
to accept any ONE of these character encoding schemes for
each part of a multipart entity. The client may perform
character encoding translation to satisfy the server if
necessary.
NOTE -- The default value for the ACCEPT-CHARSET attribute
of an INPUT or TEXTAREA element is the reserved value
"UNKNOWN". A user agent may interpret that value as the
character encoding scheme that was used to transmit the
document containing that element.
5.2. Form submission
The HTML 2.0 form submission mechanism, based on the "application/x-
www-form-urlencoded" media type, is ill-equipped with regard to
internationalization. In fact, since URLs are restricted to ASCII
characters, the mechanism is akward even for ISO-8859-1 text. Sec-
tion 2.2 of [RFC1738] specifies that octets may be encoded using the
"%HH" notation, but text submitted from a form is composed of charac-
ters, not octets. Lacking a specification of a character encoding
scheme, the "%HH" notation has no well-defined meaning.
A partial solution to this sorry state of affairs is to specify a
default character encoding scheme to be assumed when the GET method
of form submission is used. Specifying UCS-2 would break all exist-
ing forms, so the only sensible way is to designate ISO-8859-1. That
is, the encoded URL sent to submit a form by the GET method is to be
interpreted as a sequence of single-octet characters encoded accord-
ing to ISO-8859-1, and further encoded according to the scheme of
[RFC1738] (the "%HH" notation). This is clearly insufficient, so
designers of forms are advised to use the POST method of form submis-
sion whenever possible.
A better solution is to add a MIME charset parameter to the
Expires 18 August 1996 [Page 12]
Internet Draft HTML internationalization 13 February 1996
"application/x-www-form-urlencoded" media type specifier sent along
with a POST method form submission, with the understanding that the
URL encoding of [RFC1738] is applied on top of the specified charac-
ter encoding, as a kind of implicit Content-Transfer-Encoding. The
default ISO-8859-1 is implied in the absence of a charset parameter.
The best solution is to use the "multipart/form-data" media type
described in [RFC1867] with the POST method of form submission. This
mechanism encapsulates the value part of each name-value pair in a
body-part of a multipart MIME body that is sent as the HTTP entity;
each body part can be labeled with an appropriate Content-Type,
including if necessary a charset parameter that specifies the charac-
ter encoding scheme. The changes to the DTD necessary to support
this method of form submission have been incorporated in the DTD
included in this specification.
How the user agent determines the encoding of the text entered by the
user is outside the scope of this specification.
NOTE -- Designers of forms and their handling scripts
should be aware of an important caveat: when the default
value of a field (the VALUE attribute) is returned upon
form submission (i.e. the user did not modify this value),
it cannot be guaranteed to be transmitted as a sequence of
octets identical to that in the source document -- only as
a possibly different but valid encoding of the same
sequence of characters.
This may be true even if the encoding of the document con-
taining the form and that used for submission are the same,
because only the sequence of characters of the default
value, not the actual sequence of octets, may be counted on
to be preserved.
6. Miscellaneous
Proper interpretation of a text document requires that the character
encoding scheme be known. Current HTTP servers, however, do not gen-
erally include an appropriate charset parameter with the Content-Type
header, even when the encoding scheme is different from the default
ISO-8859-1. This is bad behaviour [3] , and as such strongly
_________________________
[3] This bad behaviour is even encouraged by the con-
tinued existence of browsers that declare an unrecog-
nized media type when they receive a charset parameter.
User agent implementators are strongly encouraged to
make their software tolerant of this parameter, even if
they cannot take advantage of it.
Expires 18 August 1996 [Page 13]
Internet Draft HTML internationalization 13 February 1996
discouraged, but some preventive measures can be taken to minimize
the detrimental effects.
In the case where a document is accessed from a hyperlink in an ori-
gin HTML document, a CHARSET attribute is added to the attribute list
of elements with link semantics (A and LINK), specifically by adding
it to the linkExtraAttributes entity. The value of that attribute is
to be considered a hint to the User Agent as to the character encod-
ing scheme used by the ressource pointed to by the hyperlink; it
should be the appropriate value of the MIME charset parameter for
that ressource.
In any document, it is possible to include an indication of the
encoding scheme like the following, as early as possible within the
HEAD of the document:
<META HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-2022-JP">
This is not foolproof, but will work if the encoding scheme is such
that ASCII characters stand for themselves at least until the META
element is parsed. Note that there are better ways for a server to
obtain character encoding information, instead of the unreliable
<META> above; see [NICOL2] for some details and a proposal.
For definiteness, the "charset" parameter received from the source of
the document should be considered the most authoritative, followed in
order of preference by the contents of a META element such as the
above, and finally the CHARSET parameter of the anchor that was fol-
lowed (if any).
When HTML text is transmitted directly in UCS-2
(charset=UNICODE-1-1), the question of byte order arises: does the
high-order byte of each two-byte character come first or second? For
definiteness, this specification recommends that UCS-2 be transmitted
in big-endian byte order (high order byte first), which corresponds
to the established network byte order for two-byte quantities, to the
Unicode recommendation for serialized text data and to RFC 1641.
Furthermore, to maximize chances of proper interpretation, it is rec-
ommended that documents transmitted as UCS-2 always begin with a
ZERO-WIDTH NON-BREAKING SPACE character (hexadecimal FEFF) which,
when byte-reversed becomes number FFFE, a character guaranteed to be
never assigned. Thus, a user-agent receiving an FFFE as the first
octets of a text would know that bytes have to be reversed for the
remainder of the text.
There exist so-called UCS Transformation Formats than can be used to
transmit UCS data, in addition to UCS-2. UTF-7 [RFC1642] and UTF-8
Expires 18 August 1996 [Page 14]
Internet Draft HTML internationalization 13 February 1996
[UTF-8] have interesting properties (no byte-ordering problem, dif-
ferent flavours of ASCII compatibility) that make them worthy of con-
sideration, especially for transmission of multilingual text. The
UTF-1 transformation format of ISO 10646 (registered by IANA as
ISO-10646-UTF-1), has been removed from ISO 10646, and should not be
used.
7. HTML Public Text
7.1. HTML DTD
This section contains a DTD for HTML based on the HTML 2.0 DTD of RFC
1866, incorporating the changes for file upload as specified in RFC
1867, and the changes deriving from this document.
<!-- html.dtd
Document Type Definition for the HyperText Markup Language,
extended for internationalisation (HTML DTD)
Last revised: 96/01/23
Authors: Daniel W. Connolly <connolly@w3.org>
Francois Yergeau <yergeau@alis.com>
See Also: html.decl, html-1.dtd
http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
-->
<!ENTITY % HTML.Version
"-//IETF//DTD HTML//EN"
-- Typical usage:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
...
</html>
--
>
<!--============ Feature Test Entities ========================-->
<!ENTITY % HTML.Recommended "IGNORE"
-- Certain features of the language are necessary for
compatibility with widespread usage, but they may
compromise the structural integrity of a document.
This feature test entity enables a more prescriptive
Expires 18 August 1996 [Page 15]
Internet Draft HTML internationalization 13 February 1996
document type definition that eliminates
those features.
-->
<![ %HTML.Recommended [
<!ENTITY % HTML.Deprecated "IGNORE">
]]>
<!ENTITY % HTML.Deprecated "INCLUDE"
-- Certain features of the language are necessary for
compatibility with earlier versions of the specification,
but they tend to be used and implemented inconsistently,
and their use is deprecated. This feature test entity
enables a document type definition that eliminates
these features.
-->
<!ENTITY % HTML.Highlighting "INCLUDE"
-- Use this feature test entity to validate that a
document uses no highlighting tags, which may be
ignored on minimal implementations.
-->
<!ENTITY % HTML.Forms "INCLUDE"
-- Use this feature test entity to validate that a document
contains no forms, which may not be supported in minimal
implementations
-->
<!--============== Imported Names ==============================-->
<!ENTITY % Content-Type "CDATA"
-- meaning an internet media type
(aka MIME content type, as per RFC1521)
-->
<!ENTITY % HTTP-Method "GET | POST"
-- as per HTTP specification, in progress
-->
<!--========= DTD "Macros" =====================-->
<!ENTITY % heading "H1|H2|H3|H4|H5|H6">
<!ENTITY % list " UL | OL | DIR | MENU " >
<!ENTITY % attrs -- common attributes for elements --
"LANG NAME #IMPLIED -- RFC 1766 language tag --
Expires 18 August 1996 [Page 16]
Internet Draft HTML internationalization 13 February 1996
DIR (ltr|rtl) #IMPLIED -- text directionnality --
id ID #IMPLIED -- element identifier --
class NAMES #IMPLIED -- for subclassing elements --">
<!ENTITY % just -- an attribute for text justification --
"ALIGN (left|right|center|justify) #IMPLIED">
<!--======= Character mnemonic entities =================-->
<!ENTITY % ISOlat1 PUBLIC
"ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
%ISOlat1;
<!ENTITY amp CDATA "&" -- ampersand -->
<!ENTITY gt CDATA ">" -- greater than -->
<!ENTITY lt CDATA "<" -- less than -->
<!ENTITY quot CDATA """ -- double quote -->
<!--Entities for language-dependent presentation (BIDI and contextual analysis) -->
<!ENTITY zwnj CDATA "‌"-- zero width non-joiner-->
<!ENTITY zwj CDATA "‍"-- zero width joiner-->
<!ENTITY lrm CDATA "‎"-- left-to-right mark-->
<!ENTITY rlm CDATA "‏"-- right-to-left mark-->
<!--========= SGML Document Access (SDA) Parameter Entities =====-->
<!-- HTML 2.0 contains SGML Document Access (SDA) fixed attributes
in support of easy transformation to the International Committee
for Accessible Document Design (ICADD) DTD
"-//EC-USA-CDA/ICADD//DTD ICADD22//EN".
ICADD applications are designed to support usable access to
structured information by print-impaired individuals through
Braille, large print and voice synthesis. For more information on
SDA & ICADD:
- ISO 12083:1993, Annex A.8, Facilities for Braille,
large print and computer voice
- ICADD ListServ
<ICADD%ASUACAD.BITNET@ARIZVM1.ccit.arizona.edu>
- Usenet news group bit.listserv.easi
- Recording for the Blind, +1 800 221 4792
-->
<!ENTITY % SDAFORM "SDAFORM CDATA #FIXED"
-- one to one mapping -->
<!ENTITY % SDARULE "SDARULE CDATA #FIXED"
-- context-sensitive mapping -->
<!ENTITY % SDAPREF "SDAPREF CDATA #FIXED"
Expires 18 August 1996 [Page 17]
Internet Draft HTML internationalization 13 February 1996
-- generated text prefix -->
<!ENTITY % SDASUFF "SDASUFF CDATA #FIXED"
-- generated text suffix -->
<!ENTITY % SDASUSP "SDASUSP NAME #FIXED"
-- suspend transform process -->
<!--========== Text Markup =====================-->
<![ %HTML.Highlighting [
<!ENTITY % font " TT | B | I ">
<!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE ">
<!ENTITY % text "#PCDATA|A|IMG|BR|%phrase|%font|SPAN|Q|BDO|SUP|SUB">
<!ELEMENT (%font;|%phrase) - - (%text)*>
<!ATTLIST ( TT | CODE | SAMP | KBD | VAR )
%attrs;
%SDAFORM; "Lit"
>
<!ATTLIST ( B | STRONG )
%attrs;
%SDAFORM; "B"
>
<!ATTLIST ( I | EM | CITE )
%attrs;
%SDAFORM; "It"
>
<!-- <TT> Typewriter text -->
<!-- <B> Bold text -->
<!-- <I> Italic text -->
<!-- <EM> Emphasized phrase -->
<!-- <STRONG> Strong emphasis -->
<!-- <CODE> Source code phrase -->
<!-- <SAMP> Sample text or characters -->
<!-- <KBD> Keyboard phrase, e.g. user input -->
<!-- <VAR> Variable phrase or substitutable -->
<!-- <CITE> Name or title of cited work -->
<!ENTITY % pre.content "#PCDATA|A|HR|BR|%font|%phrase|SPAN|BDO">
]]>
<!ENTITY % text "#PCDATA|A|IMG|BR|SPAN|Q|BDO|SUP|SUB">
Expires 18 August 1996 [Page 18]
Internet Draft HTML internationalization 13 February 1996
<!ELEMENT BR - O EMPTY>
<!ATTLIST BR
%SDAPREF; "&#RE;"
>
<!-- <BR> Line break -->
<!ELEMENT SPAN - - (%text)*>
<!ATTLIST SPAN
%attrs;
%SDAFORM; "other #Attlist"
>
<!-- <SPAN> Generic container -->
<!ELEMENT Q - - (%text)*>
<!ATTLIST Q
%attrs;
%SDAPREF; '"'
%SDASUFF; '"'
>
<!-- <Q> Short quotation -->
<!ELEMENT BDO - - (%text)+>
<!ATTLIST BDO
LANG NAME #IMPLIED
DIR (ltr|rtl) #REQUIRED
%SDAPREF "Bidi Override #Attval(DIR): "
%SDASUFF "End Bidi"
>
<!-- <BDO> Control bidirectionnal text -->
<!ELEMENT (SUP|SUB) - - (#PCDATA)>
<!ATTLIST (SUP)
%attrs;
%SDAPREF "Superscript(#content)"
>
<!ATTLIST (SUB)
%attrs;
%SDAPREF "Subscript(#content)"
>
<!-- <SUP> Superscript -->
<!-- <SUB> Subscript -->
<!--========= Link Markup ======================-->
Expires 18 August 1996 [Page 19]
Internet Draft HTML internationalization 13 February 1996
<!ENTITY % linkType "NAMES">
<!ENTITY % linkExtraAttributes
"REL %linkType #IMPLIED
REV %linkType #IMPLIED
URN CDATA #IMPLIED
TITLE CDATA #IMPLIED
METHODS NAMES #IMPLIED
CHARSET NAME #IMPLIED
">
<![ %HTML.Recommended [
<!ENTITY % A.content "(%text)*"
-- <H1><a name="xxx">Heading</a></H1>
is preferred to
<a name="xxx"><H1>Heading</H1></a>
-->
]]>
<!ENTITY % A.content "(%heading|%text)*">
<!ELEMENT A - - %A.content -(A)>
<!ATTLIST A
%attrs;
HREF CDATA #IMPLIED
NAME CDATA #IMPLIED
%linkExtraAttributes;
%SDAPREF; "<Anchor: #AttList>"
>
<!-- <A> Anchor; source/destination of link -->
<!-- <A NAME="..."> Name of this anchor -->
<!-- <A HREF="..."> Address of link destination -->
<!-- <A URN="..."> Permanent address of destination -->
<!-- <A REL=...> Relationship to destination -->
<!-- <A REV=...> Relationship of destination to this -->
<!-- <A TITLE="..."> Title of destination (advisory) -->
<!-- <A METHODS="..."> Operations on destination (advisory) -->
<!-- <A CHARSET="..."> Charset of destination (advisory) -->
<!--========== Images ==========================-->
<!ELEMENT IMG - O EMPTY>
<!ATTLIST IMG
%attrs;
SRC CDATA #REQUIRED
ALT CDATA #IMPLIED
ALIGN (top|middle|bottom) #IMPLIED
Expires 18 August 1996 [Page 20]
Internet Draft HTML internationalization 13 February 1996
ISMAP (ISMAP) #IMPLIED
%SDAPREF; "<Fig><?SDATrans Img: #AttList>#AttVal(Alt)</Fig>"
>
<!-- <IMG> Image; icon, glyph or illustration -->
<!-- <IMG SRC="..."> Address of image object -->
<!-- <IMG ALT="..."> Textual alternative -->
<!-- <IMG ALIGN=...> Position relative to text -->
<!-- <IMG ISMAP> Each pixel can be a link -->
<!--========== Paragraphs=======================-->
<!ELEMENT P - O (%text)*>
<!ATTLIST P
%attrs;
%just;
%SDAFORM; "Para"
>
<!-- <P> Paragraph -->
<!--========== Headings, Titles, Sections ===============-->
<!ELEMENT HR - O EMPTY>
<!ATTLIST HR
DIR (ltr|rtl) #IMPLIED
%just;
%SDAPREF; "&#RE;&#RE;"
>
<!-- <HR> Horizontal rule -->
<!ELEMENT ( %heading ) - - (%text;)*>
<!ATTLIST H1
%attrs;
%just;
%SDAFORM; "H1"
>
<!ATTLIST H2
%attrs;
%just;
%SDAFORM; "H2"
>
<!ATTLIST H3
%attrs;
%just;
%SDAFORM; "H3"
Expires 18 August 1996 [Page 21]
Internet Draft HTML internationalization 13 February 1996
>
<!ATTLIST H4
%attrs;
%just;
%SDAFORM; "H4"
>
<!ATTLIST H5
%attrs;
%just;
%SDAFORM; "H5"
>
<!ATTLIST H6
%attrs;
%just;
%SDAFORM; "H6"
>
<!-- <H1> Heading, level 1 -->
<!-- <H2> Heading, level 2 -->
<!-- <H3> Heading, level 3 -->
<!-- <H4> Heading, level 4 -->
<!-- <H5> Heading, level 5 -->
<!-- <H6> Heading, level 6 -->
<!--========== Text Flows ======================-->
<![ %HTML.Forms [
<!ENTITY % block.forms "BLOCKQUOTE | FORM | ISINDEX">
]]>
<!ENTITY % block.forms "BLOCKQUOTE">
<![ %HTML.Deprecated [
<!ENTITY % preformatted "PRE | XMP | LISTING">
]]>
<!ENTITY % preformatted "PRE">
<!ENTITY % block "P | %list | DL
| %preformatted
| %block.forms">
<!ENTITY % flow "(%text|%block)*">
<!ENTITY % pre.content "#PCDATA | A | HR | BR | SPAN | BDO">
<!ELEMENT PRE - - (%pre.content)*>
<!ATTLIST PRE
Expires 18 August 1996 [Page 22]
Internet Draft HTML internationalization 13 February 1996
%attrs;
WIDTH NUMBER #implied
%SDAFORM; "Lit"
>
<!-- <PRE> Preformatted text -->
<!-- <PRE WIDTH=...> Maximum characters per line -->
<![ %HTML.Deprecated [
<!ENTITY % literal "CDATA"
-- historical, non-conforming parsing mode where
the only markup signal is the end tag
in full
-->
<!ELEMENT (XMP|LISTING) - - %literal>
<!ATTLIST XMP
%attrs;
%SDAFORM; "Lit"
%SDAPREF; "Example:&#RE;"
>
<!ATTLIST LISTING
%attrs;
%SDAFORM; "Lit"
%SDAPREF; "Listing:&#RE;"
>
<!-- <XMP> Example section -->
<!-- <LISTING> Computer listing -->
<!ELEMENT PLAINTEXT - O %literal>
<!-- <PLAINTEXT> Plain text passage -->
<!ATTLIST PLAINTEXT
%attrs;
%SDAFORM; "Lit"
>
]]>
<!--========== Lists ==================-->
<!ELEMENT DL - - (DT | DD)+>
<!ATTLIST DL
%attrs;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
Expires 18 August 1996 [Page 23]
Internet Draft HTML internationalization 13 February 1996
%SDAPREF; "Definition List:"
>
<!ELEMENT DT - O (%text)*>
<!ATTLIST DT
%attrs;
%SDAFORM; "Term"
>
<!ELEMENT DD - O %flow>
<!ATTLIST DD
%attrs;
%SDAFORM; "LItem"
>
<!-- <DL> Definition list, or glossary -->
<!-- <DL COMPACT> Compact style list -->
<!-- <DT> Term in definition list -->
<!-- <DD> Definition of term -->
<!ELEMENT (OL|UL) - - (LI)+>
<!ATTLIST OL
%attrs;
%just;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
>
<!ATTLIST UL
%attrs;
%just;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
>
<!-- <UL> Unordered list -->
<!-- <UL COMPACT> Compact list style -->
<!-- <OL> Ordered, or numbered list -->
<!-- <OL COMPACT> Compact list style -->
<!ELEMENT (DIR|MENU) - - (LI)+ -(%block)>
<!ATTLIST DIR
%attrs;
%just;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
%SDAPREF; "<LHead>Directory</LHead>"
>
<!ATTLIST MENU
Expires 18 August 1996 [Page 24]
Internet Draft HTML internationalization 13 February 1996
%attrs;
%just;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
%SDAPREF; "<LHead>Menu</LHead>"
>
<!-- <DIR> Directory list -->
<!-- <DIR COMPACT> Compact list style -->
<!-- <MENU> Menu list -->
<!-- <MENU COMPACT> Compact list style -->
<!ELEMENT LI - O %flow>
<!ATTLIST LI
%attrs;
%just;
%SDAFORM; "LItem"
>
<!-- <LI> List item -->
<!--========== Document Body ===================-->
<![ %HTML.Recommended [
<!ENTITY % body.content "(%heading|%block|HR|ADDRESS|IMG)*"
-- <h1>Heading</h1>
<p>Text ...
is preferred to
<h1>Heading</h1>
Text ...
-->
]]>
<!ENTITY % body.content "(%heading | %text | %block |
HR | ADDRESS)*">
<!ELEMENT BODY O O %body.content>
<!ATTLIST BODY
%attrs;
>
<!-- <BODY> Document body -->
<!ELEMENT BLOCKQUOTE - - %body.content>
<!ATTLIST BLOCKQUOTE
%attrs;
%just;
%SDAFORM; "BQ"
Expires 18 August 1996 [Page 25]
Internet Draft HTML internationalization 13 February 1996
>
<!-- <BLOCKQUOTE> Quoted passage -->
<!ELEMENT ADDRESS - - (%text|P)*>
<!ATTLIST ADDRESS
%attrs;
%just;
%SDAFORM; "Lit"
%SDAPREF; "Address:&#RE;"
>
<!-- <ADDRESS> Address, signature, or byline -->
<!--======= Forms ====================-->
<![ %HTML.Forms [
<!ELEMENT FORM - - %body.content -(FORM) +(INPUT|SELECT|TEXTAREA)>
<!ATTLIST FORM
%attrs;
ACTION CDATA #IMPLIED
METHOD (%HTTP-Method) GET
ENCTYPE %Content-Type; "application/x-www-form-urlencoded"
%SDAPREF; "<Para>Form:</Para>"
%SDASUFF; "<Para>Form End.</Para>"
>
<!-- <FORM> Fill-out or data-entry form -->
<!-- <FORM ACTION="..."> Address for completed form -->
<!-- <FORM METHOD=...> Method of submitting form -->
<!-- <FORM ENCTYPE="..."> Representation of form data -->
<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |
RADIO | SUBMIT | RESET |
IMAGE | HIDDEN | FILE )">
<!ELEMENT INPUT - O EMPTY>
<!ATTLIST INPUT
%attrs;
TYPE %InputType TEXT
NAME CDATA #IMPLIED
VALUE CDATA #IMPLIED
SRC CDATA #IMPLIED
CHECKED (CHECKED) #IMPLIED
SIZE CDATA #IMPLIED
MAXLENGTH NUMBER #IMPLIED
ALIGN (top|middle|bottom) #IMPLIED
Expires 18 August 1996 [Page 26]
Internet Draft HTML internationalization 13 February 1996
ACCEPT CDATA #IMPLIED --list of content types --
ACCEPT-CHARSET CDATA #IMPLIED --list of charsets --
%SDAPREF; "Input: "
>
<!-- <INPUT> Form input datum -->
<!-- <INPUT TYPE=...> Type of input interaction -->
<!-- <INPUT NAME=...> Name of form datum -->
<!-- <INPUT VALUE="..."> Default/initial/selected value -->
<!-- <INPUT SRC="..."> Address of image -->
<!-- <INPUT CHECKED> Initial state is "on" -->
<!-- <INPUT SIZE=...> Field size hint -->
<!-- <INPUT MAXLENGTH=...> Data length maximum -->
<!-- <INPUT ALIGN=...> Image alignment -->
<!ELEMENT SELECT - - (OPTION+) -(INPUT|SELECT|TEXTAREA)>
<!ATTLIST SELECT
%attrs;
NAME CDATA #REQUIRED
SIZE NUMBER #IMPLIED
MULTIPLE (MULTIPLE) #IMPLIED
%SDAFORM; "List"
%SDAPREF;
"<LHead>Select #AttVal(Multiple)</LHead>"
>
<!-- <SELECT> Selection of option(s) -->
<!-- <SELECT NAME=...> Name of form datum -->
<!-- <SELECT SIZE=...> Options displayed at a time -->
<!-- <SELECT MULTIPLE> Multiple selections allowed -->
<!ELEMENT OPTION - O (#PCDATA)*>
<!ATTLIST OPTION
%attrs;
SELECTED (SELECTED) #IMPLIED
VALUE CDATA #IMPLIED
%SDAFORM; "LItem"
%SDAPREF;
"Option: #AttVal(Value) #AttVal(Selected)"
>
<!-- <OPTION> A selection option -->
<!-- <OPTION SELECTED> Initial state -->
<!-- <OPTION VALUE="..."> Form datum value for this option-->
<!ELEMENT TEXTAREA - - (#PCDATA)* -(INPUT|SELECT|TEXTAREA)>
<!ATTLIST TEXTAREA
%attrs;
Expires 18 August 1996 [Page 27]
Internet Draft HTML internationalization 13 February 1996
NAME CDATA #REQUIRED
ROWS NUMBER #REQUIRED
COLS NUMBER #REQUIRED
ACCEPT-CHARSET CDATA #IMPLIED -- list of charsets --
%SDAFORM; "Para"
%SDAPREF; "Input Text -- #AttVal(Name): "
>
<!-- <TEXTAREA> An area for text input -->
<!-- <TEXTAREA NAME=...> Name of form datum -->
<!-- <TEXTAREA ROWS=...> Height of area -->
<!-- <TEXTAREA COLS=...> Width of area -->
]]>
<!--======= Document Head ======================-->
<![ %HTML.Recommended [
<!ENTITY % head.extra "">
]]>
<!ENTITY % head.extra "& NEXTID?">
<!ENTITY % head.content "TITLE & ISINDEX? & BASE? %head.extra">
<!ELEMENT HEAD O O (%head.content) +(META|LINK)>
<!ATTLIST HEAD
%attrs; >
<!-- <HEAD> Document head -->
<!ELEMENT TITLE - - (#PCDATA)* -(META|LINK)>
<!ATTLIST TITLE
%attrs;
%SDAFORM; "Ti" >
<!-- <TITLE> Title of document -->
<!ELEMENT LINK - O EMPTY>
<!ATTLIST LINK
%attrs;
HREF CDATA #REQUIRED
%linkExtraAttributes;
%SDAPREF; "Linked to : #AttVal (TITLE) (URN) (HREF)>" >
<!-- <LINK> Link from this document -->
<!-- <LINK HREF="..."> Address of link destination -->
<!-- <LINK URN="..."> Lasting name of destination -->
Expires 18 August 1996 [Page 28]
Internet Draft HTML internationalization 13 February 1996
<!-- <LINK REL=...> Relationship to destination -->
<!-- <LINK REV=...> Relationship of destination to this -->
<!-- <LINK TITLE="..."> Title of destination (advisory) -->
<!-- <LINK CHARSET="..."> Charset of destination (advisory) -->
<!-- <LINK METHODS="..."> Operations allowed (advisory) -->
<!ELEMENT ISINDEX - O EMPTY>
<!ATTLIST ISINDEX
%attrs;
%SDAPREF;
"<Para>[Document is indexed/searchable.]</Para>">
<!-- <ISINDEX> Document is a searchable index -->
<!ELEMENT BASE - O EMPTY>
<!ATTLIST BASE
HREF CDATA #REQUIRED >
<!-- <BASE> Base context document -->
<!-- <BASE HREF="..."> Address for this document -->
<!ELEMENT NEXTID - O EMPTY>
<!ATTLIST NEXTID
N CDATA #REQUIRED >
<!-- <NEXTID> Next ID to use for link name -->
<!-- <NEXTID N=...> Next ID to use for link name -->
<!ELEMENT META - O EMPTY>
<!ATTLIST META
HTTP-EQUIV NAME #IMPLIED
NAME NAME #IMPLIED
CONTENT CDATA #REQUIRED >
<!-- <META> Generic Meta-information -->
<!-- <META HTTP-EQUIV=...> HTTP response header name -->
<!-- <META NAME=...> Meta-information name -->
<!-- <META CONTENT="..."> Associated information -->
<!--======= Document Structure =================-->
<![ %HTML.Deprecated [
<!ENTITY % html.content "HEAD, BODY, PLAINTEXT?">
]]>
<!ENTITY % html.content "HEAD, BODY">
<!ELEMENT HTML O O (%html.content)>
<!ENTITY % version.attr "VERSION CDATA #FIXED '%HTML.Version;'">
Expires 18 August 1996 [Page 29]
Internet Draft HTML internationalization 13 February 1996
<!ATTLIST HTML
%attrs;
%version.attr;
%SDAFORM; "Book"
>
<!-- <HTML> HTML Document -->
7.2. SGML Declaration for HTML
<!SGML "ISO 8879:1986"
--
SGML Declaration for HyperText Markup Language version 2.x
(HTML 2.x = HTML 2.0 + i18n).
--
CHARSET
BASESET "ISO Registration Number 176//CHARSET
ISO/IEC 10646-1:1993 UCS-2 with
implementation level 3//ESC 2/5 2/15 4/5"
DESCSET 0 9 UNUSED
9 2 9
11 2 UNUSED
13 1 13
14 18 UNUSED
32 95 32
127 1 UNUSED
128 32 UNUSED
160 65376 160
CAPACITY SGMLREF
TOTALCAP 150000
GRPCAP 150000
ENTCAP 150000
SCOPE DOCUMENT
SYNTAX
SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127
BASESET "ISO 646:1983//CHARSET
International Reference Version
(IRV)//ESC 2/5 4/0"
DESCSET 0 128 0
FUNCTION
Expires 18 August 1996 [Page 30]
Internet Draft HTML internationalization 13 February 1996
RE 13
RS 10
SPACE 32
TAB SEPCHAR 9
NAMING LCNMSTRT ""
UCNMSTRT ""
LCNMCHAR ".-"
UCNMCHAR ".-"
NAMECASE GENERAL YES
ENTITY NO
DELIM GENERAL SGMLREF
SHORTREF SGMLREF
NAMES SGMLREF
QUANTITY SGMLREF
ATTSPLEN 2100
LITLEN 1024
NAMELEN 72 -- somewhat arbitrary; taken from
internet line length conventions --
PILEN 1024
TAGLVL 100
TAGLEN 2100
GRPGTCNT 150
GRPCNT 64
FEATURES
MINIMIZE
DATATAG NO
OMITTAG YES
RANK NO
SHORTTAG YES
LINK
SIMPLE NO
IMPLICIT NO
EXPLICIT NO
OTHER
CONCUR NO
SUBDOC NO
FORMAL YES
APPINFO "SDA" -- conforming SGML Document Access application
--
>
7.3. ISO Latin 1 entity set
The following public text lists each of the characters specified in
the Added Latin 1 entity set, along with its name, syntax for use,
Expires 18 August 1996 [Page 31]
Internet Draft HTML internationalization 13 February 1996
and description. This list is derived from ISO Standard
8879:1986//ENTITIES Added Latin 1//EN. HTML includes the entire
entity set, and adds entities for all missing characters in the right
part of ISO-8859-1.
<!-- (C) International Organization for Standardization 1986
Permission to copy in any form is granted for use with
conforming SGML systems and applications as defined in
ISO 8879, provided this notice is included in all copies.
-->
<!-- Character entity set. Typical invocation:
<!ENTITY % ISOlat1 PUBLIC
"ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
%ISOlat1;
-->
<!ENTITY nbsp CDATA " " -- no-break space -->
<!ENTITY iexcl CDATA "¡" -- inverted exclamation mark -->
<!ENTITY cent CDATA "¢" -- cent sign -->
<!ENTITY pound CDATA "£" -- pound sterling sign -->
<!ENTITY curren CDATA "¤" -- general currency sign -->
<!ENTITY yen CDATA "¥" -- yen sign -->
<!ENTITY brvbar CDATA "¦" -- broken (vertical) bar -->
<!ENTITY sect CDATA "§" -- section sign -->
<!ENTITY uml CDATA "¨" -- umlaut (dieresis) -->
<!ENTITY copy CDATA "©" -- copyright sign -->
<!ENTITY ordf CDATA "ª" -- ordinal indicator, feminine -->
<!ENTITY laquo CDATA "«" -- angle quotation mark, left -->
<!ENTITY not CDATA "¬" -- not sign -->
<!ENTITY shy CDATA "­" -- soft hyphen -->
<!ENTITY reg CDATA "®" -- registered sign -->
<!ENTITY macr CDATA "¯" -- macron -->
<!ENTITY deg CDATA "°" -- degree sign -->
<!ENTITY plusmn CDATA "±" -- plus-or-minus sign -->
<!ENTITY sup2 CDATA "²" -- superscript two -->
<!ENTITY sup3 CDATA "³" -- superscript three -->
<!ENTITY acute CDATA "´" -- acute accent -->
<!ENTITY micro CDATA "µ" -- micro sign -->
<!ENTITY para CDATA "¶" -- pilcrow (paragraph sign) -->
<!ENTITY middot CDATA "·" -- middle dot -->
<!ENTITY cedil CDATA "¸" -- cedilla -->
<!ENTITY sup1 CDATA "¹" -- superscript one -->
<!ENTITY ordm CDATA "º" -- ordinal indicator, masculine -->
<!ENTITY raquo CDATA "»" -- angle quotation mark, right -->
<!ENTITY frac14 CDATA "¼" -- fraction one-quarter -->
<!ENTITY frac12 CDATA "½" -- fraction one-half -->
<!ENTITY frac34 CDATA "¾" -- fraction three-quarters -->
<!ENTITY iquest CDATA "¿" -- inverted question mark -->
<!ENTITY Agrave CDATA "À" -- capital A, grave accent -->
Expires 18 August 1996 [Page 32]
Internet Draft HTML internationalization 13 February 1996
<!ENTITY Aacute CDATA "Á" -- capital A, acute accent -->
<!ENTITY Acirc CDATA "Â" -- capital A, circumflex accent -->
<!ENTITY Atilde CDATA "Ã" -- capital A, tilde -->
<!ENTITY Auml CDATA "Ä" -- capital A, dieresis or umlaut mark -->
<!ENTITY Aring CDATA "Å" -- capital A, ring -->
<!ENTITY AElig CDATA "Æ" -- capital AE diphthong (ligature) -->
<!ENTITY Ccedil CDATA "Ç" -- capital C, cedilla -->
<!ENTITY Egrave CDATA "È" -- capital E, grave accent -->
<!ENTITY Eacute CDATA "É" -- capital E, acute accent -->
<!ENTITY Ecirc CDATA "Ê" -- capital E, circumflex accent -->
<!ENTITY Euml CDATA "Ë" -- capital E, dieresis or umlaut mark -->
<!ENTITY Igrave CDATA "Ì" -- capital I, grave accent -->
<!ENTITY Iacute CDATA "Í" -- capital I, acute accent -->
<!ENTITY Icirc CDATA "Î" -- capital I, circumflex accent -->
<!ENTITY Iuml CDATA "Ï" -- capital I, dieresis or umlaut mark -->
<!ENTITY ETH CDATA "Ð" -- capital Eth, Icelandic -->
<!ENTITY Ntilde CDATA "Ñ" -- capital N, tilde -->
<!ENTITY Ograve CDATA "Ò" -- capital O, grave accent -->
<!ENTITY Oacute CDATA "Ó" -- capital O, acute accent -->
<!ENTITY Ocirc CDATA "Ô" -- capital O, circumflex accent -->
<!ENTITY Otilde CDATA "Õ" -- capital O, tilde -->
<!ENTITY Ouml CDATA "Ö" -- capital O, dieresis or umlaut mark -->
<!ENTITY times CDATA "×" -- multiply sign -->
<!ENTITY Oslash CDATA "Ø" -- capital O, slash -->
<!ENTITY Ugrave CDATA "Ù" -- capital U, grave accent -->
<!ENTITY Uacute CDATA "Ú" -- capital U, acute accent -->
<!ENTITY Ucirc CDATA "Û" -- capital U, circumflex accent -->
<!ENTITY Uuml CDATA "Ü" -- capital U, dieresis or umlaut mark -->
<!ENTITY Yacute CDATA "Ý" -- capital Y, acute accent -->
<!ENTITY THORN CDATA "Þ" -- capital Thorn, Icelandic -->
<!ENTITY szlig CDATA "ß" -- small sharp s, German (sz ligature) -->
<!ENTITY agrave CDATA "à" -- small a, grave accent -->
<!ENTITY aacute CDATA "á" -- small a, acute accent -->
<!ENTITY acirc CDATA "â" -- small a, circumflex accent -->
<!ENTITY atilde CDATA "ã" -- small a, tilde -->
<!ENTITY auml CDATA "ä" -- small a, dieresis or umlaut mark -->
<!ENTITY aring CDATA "å" -- small a, ring -->
<!ENTITY aelig CDATA "æ" -- small ae diphthong (ligature) -->
<!ENTITY ccedil CDATA "ç" -- small c, cedilla -->
<!ENTITY egrave CDATA "è" -- small e, grave accent -->
<!ENTITY eacute CDATA "é" -- small e, acute accent -->
<!ENTITY ecirc CDATA "ê" -- small e, circumflex accent -->
<!ENTITY euml CDATA "ë" -- small e, dieresis or umlaut mark -->
<!ENTITY igrave CDATA "ì" -- small i, grave accent -->
<!ENTITY iacute CDATA "í" -- small i, acute accent -->
<!ENTITY icirc CDATA "î" -- small i, circumflex accent -->
<!ENTITY iuml CDATA "ï" -- small i, dieresis or umlaut mark -->
<!ENTITY eth CDATA "ð" -- small eth, Icelandic -->
Expires 18 August 1996 [Page 33]
Internet Draft HTML internationalization 13 February 1996
<!ENTITY ntilde CDATA "ñ" -- small n, tilde -->
<!ENTITY ograve CDATA "ò" -- small o, grave accent -->
<!ENTITY oacute CDATA "ó" -- small o, acute accent -->
<!ENTITY ocirc CDATA "ô" -- small o, circumflex accent -->
<!ENTITY otilde CDATA "õ" -- small o, tilde -->
<!ENTITY ouml CDATA "ö" -- small o, dieresis or umlaut mark -->
<!ENTITY divide CDATA "÷" -- divide sign -->
<!ENTITY oslash CDATA "ø" -- small o, slash -->
<!ENTITY ugrave CDATA "ù" -- small u, grave accent -->
<!ENTITY uacute CDATA "ú" -- small u, acute accent -->
<!ENTITY ucirc CDATA "û" -- small u, circumflex accent -->
<!ENTITY uuml CDATA "ü" -- small u, dieresis or umlaut mark -->
<!ENTITY yacute CDATA "ý" -- small y, acute accent -->
<!ENTITY thorn CDATA "þ" -- small thorn, Icelandic -->
<!ENTITY yuml CDATA "ÿ" -- small y, dieresis or umlaut mark -->
Bibliography
[BRYAN88] M. Bryan, "SGML -- An Author's Guide to the Standard
Generalized Markup Language", Addison-Wesley, Reading,
1988.
[ERCS] Extended Reference Concrete Syntax for SGML.
<http://www.sgmlopen.org/sgml/docs/ercs/ercs-
home.html>
[ETHNO] "Ethnologue, Languages of the World", 12th Edition,
Barbara F. Grimes, editor, Summer Institute of Lin-
guistics, Dallas, 1992.
[GOLD90] C. F. Goldfarb, "The SGML Handbook", Y. Rubinsky, Ed.,
Oxford University Press, 1990.
[HTTP-1.0] T. Berners-Lee, R.T. Fielding, and H. Frystyk Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", Work in
progress (draft-ietf-http-v10-spec-04.txt), MIT/LCS,
UC Irvine, October 1995.
[HTTP-1.1] R.T. Fielding, H. Frystyk Nielsen, and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", Work in
progress (draft-ietf-http-v11-spec-01.txt), MIT/LCS,
January 1996.
[ISO-639] ISO 639:1988. Codes pour la représentation des noms de
langue. Technical content in
<http://www.sil.org/sgml/iso639a.html>
Expires 18 August 1996 [Page 34]
Internet Draft HTML internationalization 13 February 1996
[ISO-3166] ISO 3166:1993. Codes pour la représentation des noms
de pays.
[ISO-8601] ISO 8601:1988. Éléments de données et formats
d'échange -- Échange d'information -- Représentation
de la date et de l'heure.
[ISO-8859-1] ISO 8859-1:1987. International Standard -- Informa-
tion Processing -- 8-bit Single-Byte Coded Graphic
Character Sets -- Part 1: Latin Alphabet No. 1.
[ISO-8879] ISO 8879:1986. International Standard -- Information
Processing -- Text and Office Systems -- Standard Gen-
eralized Markup Language (SGML).
[ISO-10646] ISO/IEC 10646-1:1993. International Standard -- Infor-
mation technology -- Universal Multiple-Octet Coded
Character Set (UCS) -- Part 1: Architecture and Basic
Multilingual Plane.
[NICOL] G.T. Nicol, "The Multilingual World Wide Web", Elec-
tronic Book Technologies, 1995,
<http://www.ebt.com/docs/multling.html>
[NICOL2] G.T. Nicol, "MIME Header Supplemented File Type", Work
in progress, <draft-nicol-mime-header-type-00.txt>,
EBT, October 1995.
[RFC1468] J. Murai, M. Crispin and E. van der Poel, "Japanese
Character Encoding for Internet Messages", RFC 1468,
Keio University, Panda Programming, June 1993.
[RFC1521] N. Borenstein and N. Freed, "MIME (Multipurpose Inter-
net Mail Extensions) Part One: Mechanisms for Specify-
ing and Describing the Format of Internet Message Bod-
ies", RFC 1521, Bellcore, Innosoft, September 1993.
[RFC1590] J. Postel, "Media Type Registration Procedure", RFC
1590, USC/ISI, March 1994.
[RFC1641] D. Goldsmith, M.Davis, "Using Unicode with MIME", RFC
1641, Taligent inc., July 1994.
[RFC1642] D. Goldsmith, M. Davis, "UTF-7: A Mail-safe Transfor-
mation Format of Unicode", RFC 1642, Taligent inc.,
July 1994.
[RFC1738] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform
Expires 18 August 1996 [Page 35]
Internet Draft HTML internationalization 13 February 1996
Resource Locators (URL)", RFC 1738, CERN, Xerox PARC,
University of Minnesota, October 1994.
[RFC1766] H. Alverstrand, "Tags for the Identification of Lan-
guages", RFC 1766, UNINETT, March 1995.
[RFC1866] T. Berners-Lee and D. Connolly, "Hypertext Markup Lan-
guage - 2.0", RFC 1866, MIT/W3C, November 1995.
[RFC1867] E. Nebel and L. Masinter, "Form-based File Upload in
HTML", RFC 1867, Xerox Corporation, November 1995.
August 1995.
[SQ91] SoftQuad, "The SGML Primer", 3rd ed., SoftQuad Inc.,
1991.
[TAKADA] Toshihiro Takada, "Multilingual Information Exchange
through the World-Wide Web", Computer Networks and
ISDN Systems, Vol. 27, No. 2, Nov. 1994 , p. 235-241.
[TEI] TEI Guidelines for Electronic Text Encoding and Inter-
change. <http://etext.virgina.edu/TEI.html>
[UNICODE] The Unicode Consortium, "The Unicode Standard --
Worldwide Character Encoding -- Version 1.0", Addison-
Wesley, Volume 1, 1991, Volume 2, 1992. The BIDI
algorithm is in appendix A of volume 1, with correc-
tions in appendix D of volume 2.
[UTF-8] X/Open Company Ltd., "File System Safe UCS Transforma-
tion Format (FSS_UTF)", X/Open Preleminary Specifica-
tion, Document Number P316. Also published in Unicode
Technical Report #4 and soon in an annex to ISO
10646-1.
[VANH90] E. van Hervijnen, "Practical SGML", Kluwer Academicq
Publishers Group, Norwell and Dordrecht, 1990.
Authors' Addresses
François Yergeau
Alis Technologies
100, boul. Alexis-Nihon
Suite 600
Montréal QC H4M 2P2
Canada
Tel: +1 (514) 747-2547
Expires 18 August 1996 [Page 36]
Internet Draft HTML internationalization 13 February 1996
Fax: +1 (514) 747-2561
EMail: fyergeau@alis.com
Gavin Thomas Nicol
Electronic Book Technologies, Japan
1-29-9 Tsurumaki,
Setagaya-ku,
Tokyo
Japan
Tel: +81-3-3230-8161
Fax: +81-3-3230-8163
EMail: gtn@ebt.com, gtn@twics.co.jp
Glenn Adams
Stonehand
118 Magazine Street
Cambridge, MA 02139
U.S.A.
Tel: +1 (617) 864-5524
Fax: +1 (617) 864-4965
EMail: glenn@stonehand.com
Martin J. Duerst
Multimedia-Laboratory
Departement of Computer Science
University of Zurich
Winterthurerstrasse 190
CH-8057 Zurich
Switzerland
Tel: +41 1 257 43 16
Fax: +41 1 363 00 35
E-mail: mduerst@ifi.unizh.ch
Expires 18 August 1996 [Page 37]