#?SuikaWiki/0.9 page-icon="HTML" import="HTML訳語集,メッセージ訳語集,RFC訳語集,その他の訳語集"
'''Compound Documents in HTML [INS[HTML における複合文書]]'''
- INTERNET DRAFT
- Expires in six months
- Paul Burchard, Princeton CS
- Dave Raggett, W3 Consortium
-
* Status of this Memo
> This document is an Internet draft. Internet drafts are working
documents of the Internet Engineering Task Force (IETF), its areas
and its working groups. Note that other groups may also distribute
working information as Internet drafts.
> Internet Drafts are draft documents valid for a maximum of six
months and can be updated, replaced or obsoleted by other documents
at any time. It is inappropriate to use Internet drafts as reference
material or to cite them as other than as "work in progress".
> To learn the current status of any Internet draft please check the
"lid-abstracts.txt" listing contained in the Internet drafts shadow
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or
ftp.isi.edu (US West coast). Further information about the IETF can
be found at URL:
> Distribution of this document is unlimited. Please send comments to
the HTML working group (HTML-WG) of the Internet Engineering Task
Force (IETF) at . Discussions of this group are
archived at URL: .
* 1. Abstract [INS[概要]]
> This specification provides an HTML implementation of a simple
compound document architecture for the World Wide Web, based on a
new element.
この仕様書は、新しい [CODE(HTML)[]] 要素に基いた、
__&&World Wide Web&&__の簡単な複合文書構造の HTML
の実装を提供します。
> By not restricting itself to a limited class of media types or media
handler implementations, this element enables portable compound
document markup, and encourages the modular design of user-agents.
Although this specification does not presume to define a concrete
API between extensible user-agents and their media handlers, some
high-level requirements are imposed on the embedding semantics in
order to ensure support for the full linking and embedding model.
__&&media type&&__や__&&media handler&&__の実装の級を制限しないことで、この要素は可搬的な複合文書__&&markup&&__を可能にし、__&&user agent&&__のモジュール化設計を推進します。
この仕様書は拡張可能な__&&user agent&&__とその__&&media handler&&__の間の具体的な
API を定義することを求めるものではありませんが、完全なリンクと埋め込みの__&&model&&__に確実に対応するために意味の埋め込みに何らかの高水準の要求が課されます。
> By making a container element, rich alternative text with
links and images is enabled. Moreover, the container element
provides superior extensibility, setting the stage for structured
enhancement of SGML content models, rather than sole dependence on
proliferation of attributes.
[CODE(HTML)[]] を__&&container&&__要素とすることで、リンクと画像による表現豊かな代替__&&text&&__が可能になります。
更に、__&&container&&__要素は SGML __&&content model&&__の構造化拡張の場とすることで、単に属性の増殖に依存するよりも優れた拡張性を提供します。
* Contents [INS[目次]]
= Abstract
.......................................................... 1
= Examples and Rationale
............................................ 2
= Compound Document Architecture
.................................... 4
= Geometry Negotiation
.............................................. 5
= HTML Markup
....................................................... 5
== Elements
...................................................... 5
== Attribute Value Types
......................................... 8
== Attribute Sets
................................................ 9
= Summary of DTD Changes for HTML
.................................. 14
= Transition Issues
................................................ 18
== Sun's APPLET Tag
............................................. 18
== Netscape's Early Implementations of EMBED
.................... 18
= Security Considerations
.......................................... 18
= Acknowledgments
.................................................. 18
= References
....................................................... 19
= Authors' Addresses
............................................... 19
* Examples and Rationale [INS[例示と理論]]
> The only compound document feature defined in HTML 2.0 [1] was the
tag for embedding image media into HTML. Although arguably,
next to , the single most influential tag in the explosive growth
of the Web, its shortcomings are now causing a proliferation of
media- and user-agent-specific attempts at extending HTML.
HTML 2.0 で定義されている唯一の複合文書機能は HTML に画像媒体を埋め込む
[CODE(HTML)[ ]] __&&tag&&__です。議論の余地はあるものの、 [CODE(HTML)[ ]]
に次いで、 Web の爆発的成長に最も影響を振るう単一の__&&tag&&__は、その不足のために、
媒体や__&&user agent&&__特定の HTML の拡張の試みの増殖を現在起こしています。
> The most serious shortcoming of the tag is its arbitrary
restriction to image media. Many of the proposed embedding
extensions also use names which suggest specialized functionality
(e.g. , ). But as modular, extensible user agents
become the norm, such restrictions become untenable. We propose that
the name EMBED is both broad and intuitive enough to denote a
generic embedding element. In order to avoid
implementation-dependent markup, it is essential that this EMBED tag
should cover all embeddable Internet media types [2], however the
corresponding media handlers are implemented (`built-ins',
`plug-ins', etc.).
[CODE(HTML)[ ]] __&&tag&&__の最も重要な問題は、画像媒体に制限してしまっていることです。
多くの埋め込み拡張の提案も特定の機能を表す名前を使っています
(例えば [CODE(HTML)[]] や [CODE(HTML)[]])。
しかしモジュール化され拡張可能な__&&user agent&&__が標準的になれば、そのような制限は維持できなくなります。
[CODE(HTML)[EMBED]] という名前は一般的な埋め込み要素を表すのに十分大雑把で直感的であると考えます。
実装依存の__&&markup&&__を避けるために、対応する__&&media handler&&__がどう実装されていようとも
(「組込み」でも「__&&plugin&&__」等でも)、この [CODE(HTML)[EMBED]] __&&tag&&__が埋め込み可能な全ての__&&Internet Media Type&&__をまかなうことが必要です。
> The second key shortcoming of the tag is that it is `empty'
(meaning that it doesn't use a closing ). Since SGML
attributes are the only mechanism then available for the expression
of element properties, all the powerful structuring capabilities of
SGML are lost. In particular, the inability to nest elements inside
an empty element means that properties with rich text values (such
as would be desirable for the alternative text of ) cannot be implemented.
[CODE(HTML)[ ]] __&&tag&&__の2つ目の問題点は、これが「__&&empty&&__」であること
(閉じ [CODE(HTML)[]] を使わないこと) です。
この場合 SGML 属性が__&&element&&__の属性を表現する唯一の利用可能な仕組みですから、
SGML の全ての強力な構造化された能力は失われます。
とりわけ、__&&empty element&&__は内部に入れ子に__&&element&&__を入れることが出来ませんから、表現豊かな__&&text&&__の値の__&&property&&__
([CODE(HTML)[ ]] の代替__&&text&&__として望ましかったものなど)
を実装できないことを意味します。
> Moreover, extensibility of empty elements suffers because everything
occurs in the a single, flat attribute namespace. Whereas empty
elements with complex properties create an "attribute soup" that may
not even be legal SGML:
更に、__&&empty element&&__では全てのものが単一の平坦な属性名前空間に含まれるために拡張性も制限されます。
複雑な__&&property&&__を持つ__&&empty element&&__は「__&&attribute soup&&__」になって、正当な
SGML でさえなくなりかねません。
[PRE[
[INS[]]
]PRE]
> complex container elements can grow in a natural way, benefitting
from the structured design of SGML:
複雑な__&&container&&____&&element&&__は、 SGML の構造化された設計の利点により自然な方法で修飾出来ます。
[PRE[
...
Download this cool application !
[INS[このイケてる''応用''を''入手'']]
[INS[__&&rich&&__代替__&&text&&__]]
]PRE]
> The ability to pass an extensible set of parameters to the embedded
media handler in this way is one of the main requirements for an
embedding tag.
拡張可能な__&¶meter&&__の集合をこの方法で埋め込まれた__&&media handler&&__に伝達する能力は、埋め込み__&&tag&&__の必要要件の一つです。
> Notice that this structured content approach also makes it possible
to combine with for excellent backwards compatibility:
この構造化された内容を使う方法は、 [CODE(HTML)[]] を [CODE(HTML)[ ]]
と組み合わせて優れた後方互換性を確保することも可能にします。
[PRE[
]PRE]
> Here, an image of the first frame of the movie will be shown
whenever the movie itself is not displayed, providing fallback for
all of the following situations:
ここで、動画自体を表示出来ない時には動画の最初の__&&frame(動画)&&__の画像が表示され、次の状況の全てに対して代替手段を提供します。
- the user-agent does not know about the tag, or
- the user-agent does not have an embeddable handler for the
video/mpeg media type, or
- the linking and embedding fails in any other way.
- __&&user agent&&__が [CODE(HTML)[]] __&&tag&&__を知らない場合
- __&&user agent&&__が [CODE[video/mpeg]] __&&media type&&__の埋め込み可能な__&&media handler&&__を持たない場合
- 他の方法でのリンク及び埋め込みが失敗した場合
* 3. Compound Document Architecture [INS[複合文書構造]]
> Because the Web, as a distributed hypermedia system, makes a clear
separation between storage and presentation of data, the model
described in this section would more accurately be called a
"compound presentation architecture". The model offered here takes a
very high-level view of client-side state, and explains how links,
the fundamental building blocks of the Web, are used to assemble
compound presentations in stateful user-agents.
Web は分散__&&hypermedia system&&__として、明確にデータの蓄積と表現を分離していますから、この節で説明する__&&model&&__はより正確には「複合表現構造」と呼ぶべきものです。
ここで示す__&&model&&__は__&&client&&__側の状態の非常に高い水準の視点を取り、
Web の基本的な構築単位であるリンクを状態を持った__&&user agent&&__でどう複合表現を組み立てるのに使用するかを説明します
> The model views the user-agent as a repository of hierarchical
presentation resources. A presentation resource is an addressable
unit of state in the user-agent, such as the document display area
of a GUI window. An embedded display area (say, showing a video)
within the larger display area (say, showing an HTML document) would
be a child in the presentation resource hierarchy. This hierarchical
structure makes it possible to use URLs (within the generic-RL
paradigm [3]) as addresses, but this document does not define or
require any specific client-side addressing schemes.
この__&&model&&__は__&&user agent&&__を階層構造の表現資源の貯蔵庫と捉えます。
表現資源は__&&user agent&&__において、 GUI 窓の文書表示領域のような__&&addressable&&__単位の状態で存在します。
大表示領域 (例えば HTML 文書を表示。) 中の埋め込み表示領域 (例えば動画を再生。)
は表現資源階層中では子供に当たります。この階層構造は__&&address&&__として
(__&&generic-RL paradigm&&__ 中の) URL を使うことを可能としますが、この文書はそうした特定の__&&client&&__側__&&addressing&&____&&scheme&&__の定義や要求はしません。
> Like server-side resources on the Web, these presentation resources
may support methods to query and change the state they hold. This
model views the standard display of a MIME entity in a presentation
resource as POSTing that entity to the resource. The implementation
of the POST method typically creates a media handler for the entity
(which does the actual work of display), pushes that media handler
onto a navigation stack, and then gives the media handler access to
the display area represented by the resource.
Web のサーバー側資源同様に、これらの表現資源は問合せたりその保持する状態を変えたりする方法を持つことが出来ます。
この__&&model&&__は表現資源中の MIME __&&entity&&__の標準の表示を、その__&&entity&&__を資源に
[CODE[POST]] するものとして捉えます。 [CODE[POST]] __&&method&&__の実装は典型的には__&&entity&&__の__&&media handler&&__を作成し、
(これは普通の表示作業をし、) その__&&media handler&&__を__&&navigation stack&&__上に押入れ、__&&media handler&&__に資源により表現される表示領域への__&&access権&&__を与えます。
> This model of the user-agent now allows us to describe an anchor
more generally as a recipe for getting a MIME entity from a
retrieval resource and posting it to a presentation resource. A
link, as always, is a relation between two anchors (known as the
tail and the head). Thus, links and anchors have the following properties:
__&&user agent&&__のこの__&&model&&__によって、__&&anchor&&__をより一般的に、取り出した資源から
MIME __&&entity&&__を得て表現し現にそれを__&&post&&__するための__&&recipe&&__として説明できます。
__&&link&&__は、常にそうであるように、2つの__&&anchor&&__
(__&&tail(anchor)&&__と__&&head(anchor)&&__として知られる。)
の関係です。従って、__&&link&&__と__&&anchor&&__は次の__&&property&&__を持ちます。
[PRE[
link:
head anchor, tail anchor, relations
]PRE]
[PRE[
anchor:
source method call:
retrieval address, method, and argument(s)
]PRE]
[PRE[
target method call:
presentation address, method, and argument(s)
]PRE]
:__&&link&&__:__&&head anchor&&__, __&&tail anchor&&__, 関係
:__&&anchor&&__:
:始点__&&method&&__呼出し:検索__&&address&&__, __&&method&&__, 引数
:終点__&&method&&__呼出し:表現__&&address&&__, __&&method&&__, 引数
> For this specification, the main point of the model is to prescribe
what information must be made available to the media handlers by the
presentation resource (this affects the design of `plug-in' APIs).
The key requirement we impose is that the media handler must have
acccess to complete link information according to the link model
just described.
この仕様では、この__&&model&&__の要点はどの情報が表現資源によって__&&media handler&&__に利用可能でなければならないかを指示するところです
(これは「__&&plugin&&__」 API の設計に影響します)。
ここで課す重要な要件は、__&&media handler&&__はただいま説明しました__&&link&&____&&model&&__に従った完全な__&&link&&__情報への接触手段を持たなければならないということです。
* 4. Geometry Negotiation [INS[幾何折衝]]
> The actual appearance of the compound presentation depends on a
negotiation between the containing and contained presentations. This
negotiation process may involve:
複合表現の実際の容姿は含める側と含まれる側の表現の間での折衝に拠ります。
この折衝過程は次のことと関係します。
- the respective style sheets of the entities presented
- the nature of the media involved (resizable or not)
- 提示される__&&entity&&__のそれぞれの__&&style sheet&&__
- 含まれる媒体の性質 (大きさを変更可能かどうか)
> [This section is incomplete.]
[この節は未完です。]
* 5. HTML Markup [INS[HTML マーク付け]]
> This specification defines an extension of the HTML 2.1 DTD [4].
This description makes free use of SGML elements and entities
defined there.
この仕様は HTML 2.1 DTD の拡張を定義します。
この説明はそちらで定義された SGML 要素・__&&entity&&__を断り無く使用します。
** 5.1. Elements [INS[要素]]
[PRE[
'
%SDASUFF; ' '
>
]PRE]
> Attributes: SRC, PARAMS; TITLE, URN, REL, REV; ACCEPT,
ACCEPT-CHARSET, ACCEPT-ENCODING; WIDTH, HEIGHT; ALIGN, HSPACE,
VSPACE, FLOWTO.
> Common Attributes: ID, LANG, DIR (implied for all elements below).
> From the point of view of the compound document architecture, the
element has two purposes:
複合文書構造の視点から、 [CODE(HTML)[]] 要素には二つの目的があります。
[PRE[
* It conditionally creates a presentation resource, a child node
in the presentation hierarchy below the presentation of the HTML
entity which contained the element.
]PRE]
[PRE[
* It declares a link for which the target of the tail anchor
implicitly uses the newly created presentation resource.
]PRE]
-
[PRE[
This functionality is implemented with the help of the
and elements:
]PRE]
[PRE[
]PRE]
[PRE[
]PRE]
[PRE[
The link is activated as soon as the parent presentation of
the HTML entity is created. If for any reason the link fails, or the
child presentation cannot be created, then the content of the
element must be rendered in place of the
element.
]PRE]
[PRE[
Note: There is never any need to actually include
tags in a document; this construct exists solely to allow
glitch-free use of %A.content in combination with
tags. The %A.content was chosen in part to aid error recovery
when the tag is accidentally omitted.
]PRE]
[PRE[
]PRE]
[PRE[
"
>
]PRE]
[PRE[
Attributes: NAME, VALUE, ACCEPT, ACCEPT-CHARSET, ACCEPT-ENCODING.
]PRE]
[PRE[
The method invoked on the presentation resource is POST, which has
two arguments. The first is the MIME [5] entity retrieved as a
result of link activation. The second argument is a MIME entity
called the presentation specializer, which is used to modify the
resulting presentation, and is a generalization of the so-called
"fragment id". This specializer can be defined in one of three ways,
in order of priority:
]PRE]
[PRE[
elements
these elements collectively define a presentation specializer of
type multipart/form-data, which is used by the media handler as
an unordered list of named parameters, each with full MIME type
information
]PRE]
[PRE[
PARAMS attribute
defines a presentation specializer of type
application/x-www-form-urlencoded, which is used by the media
handler as an unordered list of named string parameters
]PRE]
[PRE[
"fragment id" of SRC attribute
defines a presentation specializer of type text/plain, which
used as the name of the markup element on which the presentation
should be focused
]PRE]
[PRE[
If two or more of the above mechanisms is used simultaneously, the
one with higher priority wins.
]PRE]
[PRE[
]PRE]
[PRE[
Attributes: NAME, VALUE, ACCEPT, ACCEPT-CHARSET, ACCEPT-ENCODING;
TYPE; CHECKED; SRC; ALIGN, SIZE, MAXLENGTH.
]PRE]
[PRE[
The element plays a largely parallel role to , but on
the retrieval (source) end of the anchor rather than the
presentation (target) end. Unfortunately, this element has been
somewhat abused as a result of its great usefulness (though fixing
these problems is beyond the scope of this proposal).
]PRE]
[PRE[
The only modification specified here is the addition of
%mime.constraints; type information for the value of the input field
(described in detail below). Note that the %mime.constraints;
information is not intended to apply to the vestigial embedding link
defined by the SRC attribute.
]PRE]
[PRE[
]PRE]
[PRE[
]PRE]
[PRE[
Attributes: ALIGN, HSPACE, VSPACE, FLOWTO.
]PRE]
[PRE[
]PRE]
[PRE[
]PRE]
[PRE[
In typical rendering with default attributes, the italicized,
centered caption would be placed at the bottom of the area reserved
for the child presentation, and the credit would appear as smaller
roman text right-aligned near the bottom of the reserved area.
]PRE]
[PRE[
Because the caption is not an independent float, the ALIGN attribute
must be interpreted somewhat differently. Here, the value of ALIGN
indicates on which side of the reserved area the caption should be
placed. The values MIDDLE and CENTER are not meaningful.
]PRE]
[PRE[
]PRE]
[PRE[
]]>
]PRE]
[PRE[
The tag is permitted as part of %text context, meaning that
it does not force a paragraph break. The reason is that
functions as either a float (alongside the text flow) or a glyph
(part of the line of text line), but never as a block.
]PRE]
** 5.2. Attribute Value Types
[PRE[
HTML is an application of SGML for which application conventions
play a strong role, particularly in the rich syntax of its attribute
values. Although these conventions cannot be checked directly by the
SGML parser, DTD "macros" can be used help flag these conventions
for other validation tools.
]PRE]
[PRE[
]PRE]
[PRE[
]PRE]
[PRE[
Attributes values defining a length are uniformly specified as a
number followed by an optional suffix denoting the units of
measurement. The number must be an integer value or a floating-point
real value such as 2.5 (scientific notation, as in 1.2e2, is not
allowed). No white space is allowed between the number and the
suffix. The default units are screen pixels, and the following
suffixes may also be recognized: pt denotes points, pi denotes
picas, in denotes inches, cm denotes centimeters, mm denotes
millimeters, em denotes em units (in the default font), and px
denotes screen pixels.
]PRE]
[PRE[
]PRE]
[PRE[
]PRE]
[PRE[
The syntax of Uniform Resource Identifiers is given by RFC 1630 [6].
For historical reasons, attribute values of type %URI which identify
retrieval resources may also include a final "fragment identifier",
which is actually unrelated to the retrieval process and instead
specifies a presentation specializer of type text/plain.
]PRE]
5.3. Attribute Sets
[PRE[
The HTML DTD does not make extensive use elements for structuring;
instead it is typified by sets of related attributes which recur in
multiple elements. In such a setting, DTD evolution can be
facilitated by making consistent use of SGML "macros" to identify
and reuse such attribute sets.
]PRE]
[PRE[
]PRE]
[PRE[
]PRE]
[PRE[
The %attrs; attribute set is common to all elements.
]PRE]
[PRE[
ID
Used to define a document-wide identifier. This can be used for
naming positions within documents as the destination of a
hypertext link. An ID attribute value is an SGML NAME token.
(NAME tokens are formed by an initial letter followed by
letters, digits, "-" and "." characters. The letters are
restricted to A-Z and a-z.)
]PRE]
[PRE[
LANG
DIR
These attributes are described in the HTML 2.1 specification
[4].
]PRE]
[PRE[
]PRE]
[PRE[
SRC
The address of the resource to be retrieved in traversing this
link. The address must be a valid URI [6].
]PRE]
[PRE[
PARAMS
Declares a presentation method specializer argument of type
application/x-www-form-urlencoded [1]. (It is strongly recommend
to use `;' as a separator in place of `&'.) This attribute is
suitable for declaring small, simple parameter lists; more
general presentation specializers can be created using the
mechanism.
]PRE]
[PRE[
]PRE]
[PRE[
ACCEPT
ACCEPT-CHARSET
ACCEPT-ENCODING
In link-related elements, the %mime.constraints attribute-set
provides an advisory range of MIME type information, suggesting
to the data producer what is acceptable to the consumer, and to
the consumer what is available from the producer. This
attribute-set also provides specific defaults for situations in
which the MIME type information of the corresponding data cannot
otherwise be determined.
]PRE]
[PRE[
The attribute values have syntax identical to the corresponding
HTTP headers in HTTP/1.1 [7], except that the first entry of
each list must be a definite (non-wildcarded) type
specification. This first entry is used as default type
information.
]PRE]
[PRE[
As attributes of linking elements (such as ), these
constraints support efficient type-negotiation, by narrowing the
range of types in advance. For instance, a link with
ACCEPT="video/mpeg, video/*" suggests that multiple video
formats may be available for negotiation; if the the only video
format that the user-agent can usefully interpret is video/avi,
a reasonable HTTP negotiation offer would be Accept: video/avi,
video/mpeg (with a video/mpeg result stored to disk).
In link specializer elements defining name-value pairs (
and ), these attributes specify the parameter types that
should be acceptable to the method and resource in question
(retrieval and presentation resource, resp.). When the user is
allowed to change the types of the values (as is permitted by
RFC 1867 [8] for s of TYPE=FILE in '
>
"
>
Form:"
%SDASUFF; "Form End. "
>
]PRE]
* 7. Transition Issues
** 7.1. Sun's APPLET Element
[PRE[
Sun's element [9] can be mapped to with essentially
just a few name changes:
]PRE]
[PRE[
* APPLET becomes EMBED
]PRE]
[PRE[
* NAME becomes ID
]PRE]
[PRE[
* CODE is prefixed with CODEBASE to become SRC
]PRE]
[PRE[
* CODEBASE is not needed (the embedding API is required to pass
the retrieval URI (the SRC) to the media handler, from which the
CODEBASE can be deduced)
]PRE]
[PRE[
It is possible to construct peculiar examples where the CODEBASE is
not the base URI of the combination of CODEBASE with CODE, but this
seems more confusing than useful.
]PRE]
** 7.2. Netscape's Early Implementations of EMBED
[PRE[
Netscape initially implemented as an empty element [10], not
a container. While this causes some forward-compatibility problems,
the %A.content content model of allows error recovery
to occur after the first paragraph break when is omitted.
]PRE]
[PRE[
Netscape's initial implementation also uses arbitrary attributes to
pass parameters. In the interim, authors can use a combination like
the following for compatibility (though it's still not legal SGML):
]PRE]
[PRE[
*8. Security Considerations
>Immediate invocation of link without user feedback or control
aggravates security problems of links described in [11].
]PRE]
* 9. Acknowledgments
[PRE[
Dave Raggett did a lot of the early work on [12] which is
reflected here in .
]PRE]
[PRE[
Arthur van Hoff of Sun Microsystems designed based on
discussion in the hotjava-interest mailing list. This proposal has
been strongly influenced by the tag.
]PRE]
[PRE[
Dan Connolly began work to formalize the Web model [13]. Discussions
with Larry Masinter and Gavin Nicol were also important in shaping
the model presented here.
]PRE]
* 10. References
[PRE[
1. T. Berners-Lee and D. Connolly, HTML 2.0, RFC 1866.
]PRE]
[PRE[
2. J. Postel, Internet Media Types, RFC 1590.
]PRE]
[PRE[
3. R. Fielding, Relative Uniform Resource Locators, RFC 1808.
]PRE]
[PRE[
4. F. Yergeau, G. Nicol, G. Adams, and M. Duerst, HTML
Internationalization.
]PRE]
[PRE[
5. N. Borenstein and N. Freed, MIME Content Types, RFC 1521.
]PRE]
[PRE[
6. T. Berners-Lee, Universal Resource Identifiers, RFC 1630.
]PRE]
[PRE[
7. T. Berners-Lee, R. Fielding, and H. F. Nielsen, HTTP/1.1.
]PRE]
[PRE[
8. Larry Masinter et al., Form-Based File Upload in HTML, RFC 1867.
]PRE]
[PRE[
9. Sun Microsystems, APPLET Element Syntax.
]PRE]
[PRE[
10. Netscape Communications, Netscape Navigator 2.0 Feature
Descriptions
]PRE]
[PRE[
11. T. Berners-Lee, L. Masinter, and M. McCahill, Uniform Resource
Locators, RFC 1738.
]PRE]
[PRE[
12. Dave Raggett, HTML3 Draft.
]PRE]
[PRE[
13. Daniel W. Connolly, Resource Discovery and Reliable Links.
]PRE]
* 11. Authors' Addresses
[PRE[
]PRE]
[PRE[
Paul Burchard
Computer Science Dept.
Princeton University
35 Olden Street
Princeton NJ 08544
]PRE]
[PRE[
]PRE]
[PRE[
Dave Raggett
World Wide Web Consortium
Massachusetts Institute of Technology
545 Technology Square
Cambridge MA 02139
]PRE]
- [1] [[RFCのライセンス]]
[2]
Hi! Very nice site! Thanks you very much! Q5mpo6Eqrgv
([[jmhjAyj3Zj]] [JiNvV@UUAXFKm.com])