1 |
|
2 |
INTERNET DRAFT Paul Burchard, |
3 |
Princeton CS |
4 |
Expires in six months Dave Raggett, W3 |
5 |
Consortium |
6 |
|
7 |
Compound Documents in HTML |
8 |
|
9 |
<draft-ietf-html-cda-00.txt> |
10 |
|
11 |
Status of this Memo |
12 |
|
13 |
This document is an Internet draft. Internet drafts are working |
14 |
documents of the Internet Engineering Task Force (IETF), its areas |
15 |
and its working groups. Note that other groups may also distribute |
16 |
working information as Internet drafts. |
17 |
|
18 |
Internet Drafts are draft documents valid for a maximum of six |
19 |
months and can be updated, replaced or obsoleted by other documents |
20 |
at any time. It is inappropriate to use Internet drafts as reference |
21 |
material or to cite them as other than as "work in progress". |
22 |
|
23 |
To learn the current status of any Internet draft please check the |
24 |
"lid-abstracts.txt" listing contained in the Internet drafts shadow |
25 |
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), |
26 |
munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or |
27 |
ftp.isi.edu (US West coast). Further information about the IETF can |
28 |
be found at URL: http://www.cnri.reston.va.us/ |
29 |
|
30 |
Distribution of this document is unlimited. Please send comments to |
31 |
the HTML working group (HTML-WG) of the Internet Engineering Task |
32 |
Force (IETF) at <html-wg@oclc.org>. Discussions of this group are |
33 |
archived at URL: http://www.acl.lanl.gov/HTML-WG/archives.html. |
34 |
|
35 |
1. Abstract |
36 |
|
37 |
This specification provides an HTML implementation of a simple |
38 |
compound document architecture for the World Wide Web, based on a |
39 |
new <EMBED> element. |
40 |
|
41 |
By not restricting itself to a limited class of media types or media |
42 |
handler implementations, this element enables portable compound |
43 |
document markup, and encourages the modular design of user-agents. |
44 |
Although this specification does not presume to define a concrete |
45 |
API between extensible user-agents and their media handlers, some |
46 |
high-level requirements are imposed on the embedding semantics in |
47 |
order to ensure support for the full linking and embedding model. |
48 |
|
49 |
By making <EMBED> a container element, rich alternative text with |
50 |
links and images is enabled. Moreover, the container element |
51 |
provides superior extensibility, setting the stage for structured |
52 |
enhancement of SGML content models, rather than sole dependence on |
53 |
proliferation of attributes. |
54 |
|
55 |
------------------------------------------------------------------------------ |
56 |
|
57 |
|
58 |
|
59 |
Burchard and Raggett |
60 |
Page 1 |
61 |
|
62 |
|
63 |
|
64 |
Compound Documents in HTML |
65 |
|
66 |
|
67 |
Contents |
68 |
|
69 |
|
70 |
|
71 |
1. Abstract |
72 |
.......................................................... 1 |
73 |
|
74 |
2. Examples and Rationale |
75 |
............................................ 2 |
76 |
|
77 |
3. Compound Document Architecture |
78 |
.................................... 4 |
79 |
|
80 |
4. Geometry Negotiation |
81 |
.............................................. 5 |
82 |
|
83 |
5. HTML Markup |
84 |
....................................................... 5 |
85 |
|
86 |
a) Elements |
87 |
...................................................... 5 |
88 |
|
89 |
b) Attribute Value Types |
90 |
......................................... 8 |
91 |
|
92 |
c) Attribute Sets |
93 |
................................................ 9 |
94 |
|
95 |
6. Summary of DTD Changes for HTML |
96 |
.................................. 14 |
97 |
|
98 |
7. Transition Issues |
99 |
................................................ 18 |
100 |
|
101 |
a) Sun's APPLET Tag |
102 |
............................................. 18 |
103 |
|
104 |
b) Netscape's Early Implementations of EMBED |
105 |
.................... 18 |
106 |
|
107 |
8. Security Considerations |
108 |
.......................................... 18 |
109 |
|
110 |
9. Acknowledgments |
111 |
.................................................. 18 |
112 |
|
113 |
10. References |
114 |
....................................................... 19 |
115 |
|
116 |
11. Authors' Addresses |
117 |
............................................... 19 |
118 |
|
119 |
2. Examples and Rationale |
120 |
|
121 |
The only compound document feature defined in HTML 2.0 [1] was the |
122 |
<IMG> tag for embedding image media into HTML. Although arguably, |
123 |
next to <A>, the single most influential tag in the explosive growth |
124 |
of the Web, its shortcomings are now causing a proliferation of |
125 |
media- and user-agent-specific attempts at extending HTML. |
126 |
|
127 |
The most serious shortcoming of the <IMG> tag is its arbitrary |
128 |
restriction to image media. Many of the proposed embedding |
129 |
extensions also use names which suggest specialized functionality |
130 |
(e.g. <APPLET>, <FIG>). But as modular, extensible user agents |
131 |
become the norm, such restrictions become untenable. We propose that |
132 |
the name EMBED is both broad and intuitive enough to denote a |
133 |
generic embedding element. In order to avoid |
134 |
implementation-dependent markup, it is essential that this EMBED tag |
135 |
should cover all embeddable Internet media types [2], however the |
136 |
|
137 |
Burchard and Raggett |
138 |
Page 2 |
139 |
|
140 |
|
141 |
|
142 |
Compound Documents in HTML |
143 |
|
144 |
|
145 |
corresponding media handlers are implemented (`built-ins', |
146 |
`plug-ins', etc.). |
147 |
|
148 |
The second key shortcoming of the <IMG> tag is that it is `empty' |
149 |
(meaning that it doesn't use a closing </IMG>). Since SGML |
150 |
attributes are the only mechanism then available for the expression |
151 |
of element properties, all the powerful structuring capabilities of |
152 |
SGML are lost. In particular, the inability to nest elements inside |
153 |
an empty element means that properties with rich text values (such |
154 |
as would be desirable for the alternative text of <IMG>) cannot be |
155 |
implemented. |
156 |
|
157 |
Moreover, extensibility of empty elements suffers because everything |
158 |
occurs in the a single, flat attribute namespace. Whereas empty |
159 |
elements with complex properties create an "attribute soup" that may |
160 |
not even be legal SGML: |
161 |
|
162 |
|
163 |
<IMG APPLETSRC="my.applet" ALT="[applet]" FOO="23.8" |
164 |
BAR="5.0" ...> |
165 |
<!-- WRONG: cannot pass arbitrary attributes --> |
166 |
|
167 |
|
168 |
complex container elements can grow in a natural way, benefitting |
169 |
from the structured design of SGML: |
170 |
|
171 |
|
172 |
<EMBED SRC="my.applet"> |
173 |
<PARAM NAME="foo" VALUE="23.8"> |
174 |
<PARAM NAME="bar" VALUE="5.0"> |
175 |
... |
176 |
<em>Download</em> this cool <A |
177 |
HREF="my.exe">application</A>! |
178 |
<!-- rich alternative text --> |
179 |
</EMBED> |
180 |
|
181 |
|
182 |
The ability to pass an extensible set of parameters to the embedded |
183 |
media handler in this way is one of the main requirements for an |
184 |
embedding tag. |
185 |
|
186 |
Notice that this structured content approach also makes it possible |
187 |
to combine <EMBED> with <IMG> for excellent backwards compatibility: |
188 |
|
189 |
|
190 |
<EMBED SRC="movie.mpg"> |
191 |
<IMG SRC="movie.001.jpg"> <!-- first frame --> |
192 |
</EMBED> |
193 |
|
194 |
|
195 |
Here, an image of the first frame of the movie will be shown |
196 |
whenever the movie itself is not displayed, providing fallback for |
197 |
all of the following situations: |
198 |
|
199 |
* the user-agent does not know about the <EMBED> tag, or |
200 |
|
201 |
Burchard and Raggett |
202 |
Page 3 |
203 |
|
204 |
|
205 |
|
206 |
Compound Documents in HTML |
207 |
|
208 |
|
209 |
* the user-agent does not have an embeddable handler for the |
210 |
video/mpeg media type, or |
211 |
|
212 |
* the linking and embedding fails in any other way. |
213 |
|
214 |
3. Compound Document Architecture |
215 |
|
216 |
Because the Web, as a distributed hypermedia system, makes a clear |
217 |
separation between storage and presentation of data, the model |
218 |
described in this section would more accurately be called a |
219 |
"compound presentation architecture". The model offered here takes a |
220 |
very high-level view of client-side state, and explains how links, |
221 |
the fundamental building blocks of the Web, are used to assemble |
222 |
compound presentations in stateful user-agents. |
223 |
|
224 |
The model views the user-agent as a repository of hierarchical |
225 |
presentation resources. A presentation resource is an addressable |
226 |
unit of state in the user-agent, such as the document display area |
227 |
of a GUI window. An embedded display area (say, showing a video) |
228 |
within the larger display area (say, showing an HTML document) would |
229 |
be a child in the presentation resource hierarchy. This hierarchical |
230 |
structure makes it possible to use URLs (within the generic-RL |
231 |
paradigm [3]) as addresses, but this document does not define or |
232 |
require any specific client-side addressing schemes. |
233 |
|
234 |
Like server-side resources on the Web, these presentation resources |
235 |
may support methods to query and change the state they hold. This |
236 |
model views the standard display of a MIME entity in a presentation |
237 |
resource as POSTing that entity to the resource. The implementation |
238 |
of the POST method typically creates a media handler for the entity |
239 |
(which does the actual work of display), pushes that media handler |
240 |
onto a navigation stack, and then gives the media handler access to |
241 |
the display area represented by the resource. |
242 |
|
243 |
This model of the user-agent now allows us to describe an anchor |
244 |
more generally as a recipe for getting a MIME entity from a |
245 |
retrieval resource and posting it to a presentation resource. A |
246 |
link, as always, is a relation between two anchors (known as the |
247 |
tail and the head). Thus, links and anchors have the following |
248 |
properties: |
249 |
|
250 |
link: |
251 |
head anchor, tail anchor, relations |
252 |
|
253 |
anchor: |
254 |
source method call: |
255 |
retrieval address, method, and argument(s) |
256 |
|
257 |
target method call: |
258 |
presentation address, method, and argument(s) |
259 |
|
260 |
For this specification, the main point of the model is to prescribe |
261 |
what information must be made available to the media handlers by the |
262 |
|
263 |
Burchard and Raggett |
264 |
Page 4 |
265 |
|
266 |
|
267 |
|
268 |
Compound Documents in HTML |
269 |
|
270 |
|
271 |
presentation resource (this affects the design of `plug-in' APIs). |
272 |
The key requirement we impose is that the media handler must have |
273 |
acccess to complete link information according to the link model |
274 |
just described. |
275 |
|
276 |
4. Geometry Negotiation |
277 |
|
278 |
The actual appearance of the compound presentation depends on a |
279 |
negotiation between the containing and contained presentations. This |
280 |
negotiation process may involve: |
281 |
|
282 |
* the respective style sheets of the entities presented |
283 |
|
284 |
* the nature of the media involved (resizable or not) |
285 |
|
286 |
[This section is incomplete.] |
287 |
|
288 |
5. HTML Markup |
289 |
|
290 |
This specification defines an extension of the HTML 2.1 DTD [4]. |
291 |
This description makes free use of SGML elements and entities |
292 |
defined there. |
293 |
|
294 |
5.1. Elements |
295 |
|
296 |
|
297 |
|
298 |
|
299 |
<!ELEMENT EMBED - - (PARAM*, CAPTION?, EMBED.BODY, CREDIT?)> |
300 |
<!ATTLIST EMBED |
301 |
%attrs; |
302 |
%link.internal; |
303 |
%link.metainfo; |
304 |
%case.metainfo; |
305 |
%size; -- size of reserved area -- |
306 |
%align; -- alignment or float -- |
307 |
%SDAPREF; '<Fig><Xref IDRef="#AttVal(SRC)"><?SDATrans |
308 |
Embed: #AttList>' |
309 |
%SDASUFF; '</Fig>' |
310 |
> |
311 |
|
312 |
|
313 |
Attributes: SRC, PARAMS; TITLE, URN, REL, REV; ACCEPT, |
314 |
ACCEPT-CHARSET, ACCEPT-ENCODING; WIDTH, HEIGHT; ALIGN, HSPACE, |
315 |
VSPACE, FLOWTO. |
316 |
|
317 |
Common Attributes: ID, LANG, DIR (implied for all elements below). |
318 |
|
319 |
From the point of view of the compound document architecture, the |
320 |
<EMBED> element has two purposes: |
321 |
|
322 |
* It conditionally creates a presentation resource, a child node |
323 |
in the presentation hierarchy below the presentation of the HTML |
324 |
entity which contained the <EMBED> element. |
325 |
|
326 |
Burchard and Raggett |
327 |
Page 5 |
328 |
|
329 |
|
330 |
|
331 |
Compound Documents in HTML |
332 |
|
333 |
|
334 |
|
335 |
|
336 |
* It declares a link for which the target of the tail anchor |
337 |
implicitly uses the newly created presentation resource. |
338 |
|
339 |
This functionality is implemented with the help of the <EMBED.BODY> |
340 |
and <PARAM> elements: |
341 |
|
342 |
|
343 |
|
344 |
|
345 |
<!ELEMENT EMBED.BODY O O %A.content> |
346 |
<!ATTLIST EMBED.BODY |
347 |
%attrs; |
348 |
> |
349 |
|
350 |
|
351 |
The <EMBED> link is activated as soon as the parent presentation of |
352 |
the HTML entity is created. If for any reason the link fails, or the |
353 |
child presentation cannot be created, then the content of the |
354 |
<EMBED.BODY> element must be rendered in place of the <EMBED> |
355 |
element. |
356 |
|
357 |
Note: There is never any need to actually include <EMBED.BODY> |
358 |
tags in a document; this construct exists solely to allow |
359 |
glitch-free use of %A.content in combination with <PARAM> |
360 |
tags. The %A.content was chosen in part to aid error recovery |
361 |
when the </EMBED> tag is accidentally omitted. |
362 |
|
363 |
|
364 |
|
365 |
|
366 |
<!ELEMENT PARAM - O EMPTY -- builds presentation specializer -- > |
367 |
<!ATTLIST PARAM |
368 |
%attrs; |
369 |
%key.value; |
370 |
%SDAPREF; "<?SDATrans Param: #AttList>" |
371 |
> |
372 |
|
373 |
|
374 |
Attributes: NAME, VALUE, ACCEPT, ACCEPT-CHARSET, ACCEPT-ENCODING. |
375 |
|
376 |
The method invoked on the presentation resource is POST, which has |
377 |
two arguments. The first is the MIME [5] entity retrieved as a |
378 |
result of link activation. The second argument is a MIME entity |
379 |
called the presentation specializer, which is used to modify the |
380 |
resulting presentation, and is a generalization of the so-called |
381 |
"fragment id". This specializer can be defined in one of three ways, |
382 |
in order of priority: |
383 |
|
384 |
<PARAM> elements |
385 |
these elements collectively define a presentation specializer of |
386 |
type multipart/form-data, which is used by the media handler as |
387 |
|
388 |
Burchard and Raggett |
389 |
Page 6 |
390 |
|
391 |
|
392 |
|
393 |
Compound Documents in HTML |
394 |
|
395 |
|
396 |
an unordered list of named parameters, each with full MIME type |
397 |
information |
398 |
|
399 |
PARAMS attribute |
400 |
defines a presentation specializer of type |
401 |
application/x-www-form-urlencoded, which is used by the media |
402 |
handler as an unordered list of named string parameters |
403 |
|
404 |
"fragment id" of SRC attribute |
405 |
defines a presentation specializer of type text/plain, which |
406 |
used as the name of the markup element on which the presentation |
407 |
should be focused |
408 |
|
409 |
If two or more of the above mechanisms is used simultaneously, the |
410 |
one with higher priority wins. |
411 |
|
412 |
|
413 |
<!ELEMENT INPUT - O EMPTY -- builds retrieval specializer -- > |
414 |
<!ATTLIST INPUT |
415 |
%attrs; |
416 |
%key.value; -- key and MIME-typed value -- |
417 |
TYPE %InputType #IMPLIED -- defaults to TEXT in |
418 |
FORM context -- |
419 |
CHECKED (CHECKED) #IMPLIED -- initial boolean state -- |
420 |
SRC %URI; #IMPLIED -- embedded graphic for |
421 |
TYPE=IMAGE -- |
422 |
%align.simple; -- alignment for TYPE=IMAGE -- |
423 |
SIZE CDATA #IMPLIED |
424 |
MAXLENGTH NUMBER #IMPLIED |
425 |
%SDAPREF; "Input #AttVal(Type): " |
426 |
> |
427 |
|
428 |
|
429 |
Attributes: NAME, VALUE, ACCEPT, ACCEPT-CHARSET, ACCEPT-ENCODING; |
430 |
TYPE; CHECKED; SRC; ALIGN, SIZE, MAXLENGTH. |
431 |
|
432 |
The <INPUT> element plays a largely parallel role to <PARAM>, but on |
433 |
the retrieval (source) end of the anchor rather than the |
434 |
presentation (target) end. Unfortunately, this element has been |
435 |
somewhat abused as a result of its great usefulness (though fixing |
436 |
these problems is beyond the scope of this proposal). |
437 |
|
438 |
The only modification specified here is the addition of |
439 |
%mime.constraints; type information for the value of the input field |
440 |
(described in detail below). Note that the %mime.constraints; |
441 |
information is not intended to apply to the vestigial embedding link |
442 |
defined by the SRC attribute. |
443 |
|
444 |
|
445 |
|
446 |
|
447 |
<!ELEMENT CAPTION - - (%text;)+ -- caption for floating element --> |
448 |
<!ATTLIST CAPTION |
449 |
%attrs; |
450 |
%align; -- side of rectangle where |
451 |
caption placed -- |
452 |
|
453 |
Burchard and Raggett |
454 |
Page 7 |
455 |
|
456 |
|
457 |
|
458 |
Compound Documents in HTML |
459 |
|
460 |
|
461 |
%SDAPREF; "Caption: " |
462 |
> |
463 |
|
464 |
|
465 |
Attributes: ALIGN, HSPACE, VSPACE, FLOWTO. |
466 |
|
467 |
|
468 |
|
469 |
|
470 |
<!ELEMENT CREDIT - - (%text;)* -- copyright/credit for embedded |
471 |
object --> |
472 |
<!ATTLIST CREDIT |
473 |
%attrs; |
474 |
%SDAFORM; "Fn" |
475 |
> |
476 |
|
477 |
|
478 |
In typical rendering with default attributes, the italicized, |
479 |
centered caption would be placed at the bottom of the area reserved |
480 |
for the child presentation, and the credit would appear as smaller |
481 |
roman text right-aligned near the bottom of the reserved area. |
482 |
|
483 |
Because the caption is not an independent float, the ALIGN attribute |
484 |
must be interpreted somewhat differently. Here, the value of ALIGN |
485 |
indicates on which side of the reserved area the caption should be |
486 |
placed. The values MIDDLE and CENTER are not meaningful. |
487 |
|
488 |
|
489 |
|
490 |
|
491 |
<![ %HTML.Highlighting [ |
492 |
<!ENTITY % text |
493 |
"#PCDATA|A|EMBED|IMG|BR|%phrase|%font|SPAN|Q|BDO|SUP|SUB"> |
494 |
]]> |
495 |
<!ENTITY % text "#PCDATA|A|EMBED|IMG|BR|SPAN|Q|BDO|SUP|SUB"> |
496 |
|
497 |
|
498 |
The <EMBED> tag is permitted as part of %text context, meaning that |
499 |
it does not force a paragraph break. The reason is that <EMBED> |
500 |
functions as either a float (alongside the text flow) or a glyph |
501 |
(part of the line of text line), but never as a block. |
502 |
|
503 |
5.2. Attribute Value Types |
504 |
|
505 |
HTML is an application of SGML for which application conventions |
506 |
play a strong role, particularly in the rich syntax of its attribute |
507 |
values. Although these conventions cannot be checked directly by the |
508 |
SGML parser, DTD "macros" can be used help flag these conventions |
509 |
for other validation tools. |
510 |
|
511 |
|
512 |
|
513 |
|
514 |
<!ENTITY % Length "CDATA" -- number followed by optional |
515 |
units --> |
516 |
|
517 |
|
518 |
Burchard and Raggett |
519 |
Page 8 |
520 |
|
521 |
|
522 |
|
523 |
Compound Documents in HTML |
524 |
|
525 |
|
526 |
Attributes values defining a length are uniformly specified as a |
527 |
number followed by an optional suffix denoting the units of |
528 |
measurement. The number must be an integer value or a floating-point |
529 |
real value such as 2.5 (scientific notation, as in 1.2e2, is not |
530 |
allowed). No white space is allowed between the number and the |
531 |
suffix. The default units are screen pixels, and the following |
532 |
suffixes may also be recognized: pt denotes points, pi denotes |
533 |
picas, in denotes inches, cm denotes centimeters, mm denotes |
534 |
millimeters, em denotes em units (in the default font), and px |
535 |
denotes screen pixels. |
536 |
|
537 |
|
538 |
|
539 |
|
540 |
<!ENTITY % URI "CDATA" -- uniform resource identifier --> |
541 |
|
542 |
|
543 |
The syntax of Uniform Resource Identifiers is given by RFC 1630 [6]. |
544 |
For historical reasons, attribute values of type %URI which identify |
545 |
retrieval resources may also include a final "fragment identifier", |
546 |
which is actually unrelated to the retrieval process and instead |
547 |
specifies a presentation specializer of type text/plain. |
548 |
|
549 |
5.3. Attribute Sets |
550 |
|
551 |
The HTML DTD does not make extensive use elements for structuring; |
552 |
instead it is typified by sets of related attributes which recur in |
553 |
multiple elements. In such a setting, DTD evolution can be |
554 |
facilitated by making consistent use of SGML "macros" to identify |
555 |
and reuse such attribute sets. |
556 |
|
557 |
|
558 |
|
559 |
|
560 |
<!ENTITY % attrs |
561 |
'ID ID #IMPLIED -- element identifier -- |
562 |
LANG NAME #IMPLIED -- RFC 1766 language tag -- |
563 |
DIR (ltr|rtl) #IMPLIED -- text directionality --'> |
564 |
|
565 |
|
566 |
The %attrs; attribute set is common to all elements. |
567 |
|
568 |
ID |
569 |
Used to define a document-wide identifier. This can be used for |
570 |
naming positions within documents as the destination of a |
571 |
hypertext link. An ID attribute value is an SGML NAME token. |
572 |
(NAME tokens are formed by an initial letter followed by |
573 |
letters, digits, "-" and "." characters. The letters are |
574 |
restricted to A-Z and a-z.) |
575 |
|
576 |
LANG |
577 |
DIR |
578 |
These attributes are described in the HTML 2.1 specification |
579 |
|
580 |
Burchard and Raggett |
581 |
Page 9 |
582 |
|
583 |
|
584 |
|
585 |
Compound Documents in HTML |
586 |
|
587 |
|
588 |
[4]. |
589 |
|
590 |
|
591 |
<!ENTITY % link.internal -- links with implicit presentation |
592 |
resource -- |
593 |
'SRC %URI; #REQUIRED -- resource to retrieve -- |
594 |
PARAMS CDATA #IMPLIED -- presentation specializer --'> |
595 |
|
596 |
|
597 |
SRC |
598 |
The address of the resource to be retrieved in traversing this |
599 |
link. The address must be a valid URI [6]. |
600 |
|
601 |
PARAMS |
602 |
Declares a presentation method specializer argument of type |
603 |
application/x-www-form-urlencoded [1]. (It is strongly recommend |
604 |
to use `;' as a separator in place of `&'.) This attribute is |
605 |
suitable for declaring small, simple parameter lists; more |
606 |
general presentation specializers can be created using the |
607 |
<PARAM> mechanism. |
608 |
|
609 |
|
610 |
<!ENTITY % mime.constraints -- MIME typing constraints -- |
611 |
'ACCEPT CDATA "text/plain" -- applicable media |
612 |
type(s) -- |
613 |
ACCEPT-CHARSET CDATA "ISO-8859-1" -- appl. character |
614 |
encoding(s) -- |
615 |
ACCEPT-ENCODING CDATA "ISO-8859-1" -- appl. transfer |
616 |
encoding(s) --'> |
617 |
|
618 |
|
619 |
ACCEPT |
620 |
ACCEPT-CHARSET |
621 |
ACCEPT-ENCODING |
622 |
In link-related elements, the %mime.constraints attribute-set |
623 |
provides an advisory range of MIME type information, suggesting |
624 |
to the data producer what is acceptable to the consumer, and to |
625 |
the consumer what is available from the producer. This |
626 |
attribute-set also provides specific defaults for situations in |
627 |
which the MIME type information of the corresponding data cannot |
628 |
otherwise be determined. |
629 |
|
630 |
The attribute values have syntax identical to the corresponding |
631 |
HTTP headers in HTTP/1.1 [7], except that the first entry of |
632 |
each list must be a definite (non-wildcarded) type |
633 |
specification. This first entry is used as default type |
634 |
information. |
635 |
|
636 |
As attributes of linking elements (such as <EMBED>), these |
637 |
constraints support efficient type-negotiation, by narrowing the |
638 |
range of types in advance. For instance, a link with |
639 |
ACCEPT="video/mpeg, video/*" suggests that multiple video |
640 |
formats may be available for negotiation; if the the only video |
641 |
format that the user-agent can usefully interpret is video/avi, |
642 |
a reasonable HTTP negotiation offer would be Accept: video/avi, |
643 |
video/mpeg (with a video/mpeg result stored to disk). |
644 |
|
645 |
|
646 |
Burchard and Raggett |
647 |
Page 10 |
648 |
|
649 |
|
650 |
|
651 |
Compound Documents in HTML |
652 |
|
653 |
|
654 |
In link specializer elements defining name-value pairs (<INPUT> |
655 |
and <PARAM>), these attributes specify the parameter types that |
656 |
should be acceptable to the method and resource in question |
657 |
(retrieval and presentation resource, resp.). When the user is |
658 |
allowed to change the types of the values (as is permitted by |
659 |
RFC 1867 [8] for <INPUT>s of TYPE=FILE in <FORM> links, for |
660 |
example), these attributes may therefore be used constrain the |
661 |
user's changes, as a service to the eventual data consumer. In |
662 |
addition, the ACCEPT attribute (but not ACCEPT-CHARSET or |
663 |
ACCEPT-ENCODING) should be used to interpret the default value |
664 |
provided in the markup (the VALUE attribute). |
665 |
|
666 |
|
667 |
|
668 |
|
669 |
|
670 |
Note on MIME/SGML/I18N/FORM Interactions: Resources which rely on |
671 |
form submission (or presentation specializers) in an |
672 |
internationalized setting must be aware of one important caveat: |
673 |
just because the default value (the VALUE attribute) of a field is |
674 |
returned, it cannot be guaranteed to be returned as an identical |
675 |
sequence of octets -- only as (another) valid encoding of the same |
676 |
sequence of characters (under the character- and transfer-encodings |
677 |
declared for the field in the form submission). |
678 |
|
679 |
This may be true even if the character- and transfer-encodings of |
680 |
the original HTML MIME entity containing the form are the same as |
681 |
the eventual encodings used for form submission. The reason is that |
682 |
the MIME-to-SGML process is not required to preserve any of the |
683 |
encoding information of the MIME entity, only the actual sequence of |
684 |
characters in the (abstract) document character set of the SGML |
685 |
document entity. [This note should be moved to the HTML I18N draft.] |
686 |
|
687 |
|
688 |
|
689 |
|
690 |
<![ %HTML.Recommended [ |
691 |
<!ENTITY % key.value -- key/value pair with typed value -- |
692 |
'NAME NAME #IMPLIED -- keyword, usually |
693 |
required -- |
694 |
VALUE CDATA #IMPLIED -- default value -- |
695 |
%mime.constraints; -- type constraints |
696 |
for value --'> |
697 |
]]> |
698 |
<!ENTITY % key.value -- key/value pair with typed value -- |
699 |
'NAME CDATA #IMPLIED -- keyword, usually required -- |
700 |
VALUE CDATA #IMPLIED -- default value -- |
701 |
%mime.constraints; -- type constraints for |
702 |
value --'> |
703 |
|
704 |
|
705 |
NAME |
706 |
A parameter name. It is not required that NAMEs be unique keys, |
707 |
even within the scope of a single linking element; a |
708 |
multiple-values model is supported. With the strict HTML DTD, |
709 |
this attribute is a case-insensitive SGML NAME token. With the |
710 |
|
711 |
Burchard and Raggett |
712 |
Page 11 |
713 |
|
714 |
|
715 |
|
716 |
Compound Documents in HTML |
717 |
|
718 |
|
719 |
default HTML DTD, this attribute may be arbitrary CDATA, and any |
720 |
desired case-folding is the responsibility of the eventual |
721 |
consumer. |
722 |
|
723 |
VALUE |
724 |
Tags with %key.value attributes are used to collectively build |
725 |
up link specializers. Abstractly, the WWW method specializer |
726 |
resulting from such a collection of tags is the MIME entity of |
727 |
type multipart/form-data [8] which encodes all the name-value |
728 |
pairs and their types. Any %key.value tags without NAME |
729 |
attributes do not contribute to the specializer. |
730 |
|
731 |
There are two exceptions to this general model of specializer |
732 |
construction. The first is historical: in the case of <INPUT> |
733 |
tags in a <FORM>, the default is to create a specializer of type |
734 |
application/x-www-form-urlencoded (this can only unambiguously |
735 |
create a form submission with values having default MIME type). |
736 |
This historical behavior can be overridden by setting the |
737 |
<FORM>'s ENCTYPE attribute to "multipart/form-data" (which is |
738 |
strongly recommended). In case of legacy servers which require |
739 |
application/x-www-form-urlencoded form submission, but expect |
740 |
values of non-default MIME types, those expectations must be |
741 |
explicitly spelled out in the %mime.constraints. of each |
742 |
<INPUT>. |
743 |
|
744 |
The second exception provides a way to build small method |
745 |
specializers of arbitrary character-based type; the rule is that |
746 |
if exactly one instance of a %key.value tag is supplied, and |
747 |
that tag does not have a NAME attribute, then its VALUE is the |
748 |
entire specializer entity. |
749 |
|
750 |
|
751 |
|
752 |
|
753 |
<!ENTITY % link.metainfo -- overall link metainfo -- |
754 |
'TITLE CDATA #IMPLIED -- overall title for resource -- |
755 |
URN %URI #IMPLIED -- global entity name -- |
756 |
REL %linkType #IMPLIED -- link relationship -- |
757 |
REV %linkType #IMPLIED -- reverse relationship --'> |
758 |
<![ %HTML.Deprecated [ |
759 |
<!ENTITY % case.metainfo -- link metainfo for specific |
760 |
variant -- |
761 |
'%mime.constraints; -- type constraints -- |
762 |
METHODS NAMES #IMPLIED -- deprecated --'> |
763 |
]]> |
764 |
<!ENTITY % case.metainfo -- link metainfo for specific variant -- |
765 |
'%mime.constraints; -- type constraints --'> |
766 |
<!ENTITY % linkExtraAttributes |
767 |
'%link.metainfo; |
768 |
%case.metainfo; |
769 |
'> |
770 |
|
771 |
|
772 |
The link meta-information attribute set %linkExtraAttributes has |
773 |
|
774 |
Burchard and Raggett |
775 |
Page 12 |
776 |
|
777 |
|
778 |
|
779 |
Compound Documents in HTML |
780 |
|
781 |
|
782 |
been logically split into two parts to ease future extension. The |
783 |
new %case.metainfo component represents meta-information specific to |
784 |
a single link variant (currently consisting of MIME type |
785 |
information). |
786 |
|
787 |
The only other change is the deprecation of the METHODS attribute. |
788 |
It is difficult to define the semantics of the METHODS attribute in |
789 |
an object-oriented model of the Web. |
790 |
|
791 |
|
792 |
|
793 |
|
794 |
<!ENTITY % size |
795 |
'WIDTH %Length #IMPLIED -- desired width in units -- |
796 |
HEIGHT %Length #IMPLIED -- desired height in units --'> |
797 |
|
798 |
|
799 |
The %size; attribute set is used for elements that require |
800 |
bounding-box hints for rapid layout. |
801 |
|
802 |
|
803 |
|
804 |
|
805 |
<!ENTITY % align.simple |
806 |
'ALIGN (top|middle|bottom) #IMPLIED -- glyph alignment --'> |
807 |
<!ENTITY % align |
808 |
'ALIGN (top|middle|bottom|left|center|right) #IMPLIED |
809 |
HSPACE %Length #IMPLIED -- text stays this far away |
810 |
horizontally -- |
811 |
VSPACE %Length #IMPLIED -- text stays this far away |
812 |
vertically -- |
813 |
FLOWTO NAME #IMPLIED -- flow text around block |
814 |
until this ID --'> |
815 |
|
816 |
|
817 |
The %align; attribute set is used for graphic elements that can |
818 |
function either as floats or glyphs, while %align.simple; is used |
819 |
for graphic elements that function only as glyphs. |
820 |
|
821 |
ALIGN |
822 |
The value of this attribute indicates the relation between the |
823 |
graphic element and the text flow. The possible values are: |
824 |
|
825 |
|
826 |
|
827 |
LEFT |
828 |
RIGHT |
829 |
The graphic element functions as a float; subsequent text |
830 |
will be flowed around the graphic. The left (resp. right) |
831 |
edge of the graphic is aligned with the left (resp. right) |
832 |
edge of the text flow area. |
833 |
|
834 |
CENTER |
835 |
The graphic element functions as a float centered |
836 |
horizontally within the text flow area. The graphic |
837 |
interrupts the flow of text, but does not logically break |
838 |
|
839 |
Burchard and Raggett |
840 |
Page 13 |
841 |
|
842 |
|
843 |
|
844 |
Compound Documents in HTML |
845 |
|
846 |
|
847 |
the current paragraph. |
848 |
|
849 |
TOP |
850 |
BOTTOM |
851 |
The graphic element functions as a glyph within the line of |
852 |
text. The top (resp. bottom) of the graphic is aligned with |
853 |
the highest point (resp. baseline) of the rendered line of |
854 |
text. |
855 |
|
856 |
MIDDLE |
857 |
The graphic element functions as a glyph within the line of |
858 |
text. The baseline of the graphic is aligned with the |
859 |
baseline of the rendered line of text. By default, the |
860 |
baseline of the image is taken to be at its vertical center. |
861 |
(There is currently no way to override this default |
862 |
baseline.) |
863 |
|
864 |
HSPACE |
865 |
VSPACE |
866 |
The text surrounding the graphic element remains at least this |
867 |
far away. HSPACE specifies the minimum horizontal distance |
868 |
between the text and the left/right edges of the graphic, while |
869 |
VSPACE specifies the minimum vertical distance between the text |
870 |
and its top/bottom edges. This padding does not offset the |
871 |
alignment in any way. |
872 |
|
873 |
FLOWTO |
874 |
Sometimes it is important that some subsequent element appear |
875 |
below a float, rather than as part of the text flow alongside |
876 |
it; the ID of that element can be specified with the FLOWTO |
877 |
attribute. |
878 |
|
879 |
This attribute provides a more structured alternative to <BR |
880 |
CLEAR=ALL>. Its purpose is to declare the range of text with |
881 |
which the float is associated (from the element itself, until |
882 |
the element whose ID is given by FLOWTO). In typical rendering, |
883 |
the text beyond the specified range would not be flowed around |
884 |
the graphic. |
885 |
|
886 |
6. Summary of DTD Changes for HTML |
887 |
|
888 |
The resulting SGML doctype is provisionally called "-//IETF//DTD |
889 |
HTML 2.1E//EN", and is defined in terms of the doctype "-//IETF//DTD |
890 |
HTML 2.1//EN". Because the HTML 2.1 DTD [4] defines multibyte entity |
891 |
references, it must be used with an SGML declaration that provides |
892 |
an extended coded character set; the HTML 2.1E DTD inherits this |
893 |
restriction. |
894 |
|
895 |
6.1. Retroactive Modifications for HTML 2.1 |
896 |
|
897 |
The following changes are included below, but we recommend that they |
898 |
be included directly into future drafts of HTML 2.1, for |
899 |
consistency. This section will be removed from future versions of |
900 |
|
901 |
Burchard and Raggett |
902 |
Page 14 |
903 |
|
904 |
|
905 |
|
906 |
Compound Documents in HTML |
907 |
|
908 |
|
909 |
this draft, once these issues are resolved. |
910 |
|
911 |
CHARSET in %linkExtraAttributes |
912 |
Change to ACCEPT-CHARSET to allow content negotiation. |
913 |
|
914 |
ACCEPT-CHARSET in <FORM> |
915 |
Echoing comments of Larry Masinter, drop for now. This is wrong |
916 |
because it conflicts with media type metainfo for the FORM link, |
917 |
which should have priority since client Accept-ance was invented |
918 |
first! An ACCEPT-CHARSET should be given to each relevant INPUT |
919 |
instead. |
920 |
|
921 |
ACCEPT in <INPUT> |
922 |
Add ACCEPT-CHARSET and ACCEPT-ENCODING here for constraining |
923 |
input values (not in <FORM> element). |
924 |
|
925 |
METHODS in %linkExtraAttributes |
926 |
This should eventually be replaced by a per-link-variant METHOD |
927 |
attribute; multiple methods may have conflicting type |
928 |
signatures, not to mention semantics and security implications. |
929 |
|
930 |
6.2. Incremental DTD for HTML 2.1E |
931 |
|
932 |
The proposed HTML 2.1E DTD may be constructed unambiguously from the |
933 |
HTML 2.1 DTD [4] and the DTD fragment below by the following |
934 |
procedure: Entity and element definitions already in HTML 2.1 are |
935 |
overridden (respecting the marked sections); all others are added to |
936 |
the end of the DTD in the order they appear here. |
937 |
|
938 |
|
939 |
|
940 |
|
941 |
<!-- This DTD fragment shows only changes from HTML 2.1 to 2.1E --> |
942 |
|
943 |
<!ENTITY % HTML.Version "-//IETF//DTD HTML 2.1E//EN"> |
944 |
|
945 |
<!-- Content models --> |
946 |
|
947 |
<![ %HTML.Highlighting [ |
948 |
<!ENTITY % text |
949 |
"#PCDATA|A|EMBED|IMG|BR|%phrase|%font|SPAN|Q|BDO|SUP|SUB"> |
950 |
]]> |
951 |
<!ENTITY % text "#PCDATA|A|EMBED|IMG|BR|SPAN|Q|BDO|SUP|SUB"> |
952 |
|
953 |
<!-- Attribute value types --> |
954 |
|
955 |
<!ENTITY % URI "CDATA" -- uniform resource identifier --> |
956 |
<!ENTITY % Length "CDATA" -- number followed by optional |
957 |
units --> |
958 |
|
959 |
<!-- Attribute sets --> |
960 |
|
961 |
<!ENTITY % attrs |
962 |
'ID ID #IMPLIED -- element identifier -- |
963 |
LANG NAME #IMPLIED -- RFC 1766 language tag -- |
964 |
|
965 |
Burchard and Raggett |
966 |
Page 15 |
967 |
|
968 |
|
969 |
|
970 |
Compound Documents in HTML |
971 |
|
972 |
|
973 |
DIR (ltr|rtl) #IMPLIED -- text directionality --'> |
974 |
<!ENTITY % size |
975 |
'WIDTH %Length #IMPLIED -- desired width in units -- |
976 |
HEIGHT %Length #IMPLIED -- desired height in units --'> |
977 |
<!ENTITY % align.simple |
978 |
'ALIGN (top|middle|bottom) #IMPLIED -- glyph alignment --'> |
979 |
<!ENTITY % align |
980 |
'ALIGN (top|middle|bottom|left|center|right) #IMPLIED |
981 |
HSPACE %Length #IMPLIED -- text stays this far away |
982 |
horizontally -- |
983 |
VSPACE %Length #IMPLIED -- text stays this far away |
984 |
vertically -- |
985 |
FLOWTO NAME #IMPLIED -- flow text around block |
986 |
until this ID --'> |
987 |
<!ENTITY % mime.constraints -- MIME typing constraints -- |
988 |
'ACCEPT CDATA "text/plain" -- applicable media |
989 |
type(s) -- |
990 |
ACCEPT-CHARSET CDATA "ISO-8859-1" -- appl. character |
991 |
encoding(s) -- |
992 |
ACCEPT-ENCODING CDATA "ISO-8859-1" -- appl. transfer |
993 |
encoding(s) --'> |
994 |
<!ENTITY % link.internal -- links with implicit presentation |
995 |
resource -- |
996 |
'SRC %URI; #REQUIRED -- resource to retrieve -- |
997 |
PARAMS CDATA #IMPLIED -- presentation specializer -- |
998 |
USEMAP %URI #IMPLIED -- default event handling, |
999 |
if needed --'> |
1000 |
<!ENTITY % link.metainfo -- overall link metainfo -- |
1001 |
'TITLE CDATA #IMPLIED -- overall title for resource -- |
1002 |
URN %URI #IMPLIED -- global entity name -- |
1003 |
REL %linkType #IMPLIED -- link relationship -- |
1004 |
REV %linkType #IMPLIED -- reverse relationship --'> |
1005 |
<![ %HTML.Deprecated [ |
1006 |
<!ENTITY % case.metainfo -- link metainfo for specific |
1007 |
variant -- |
1008 |
'%mime.constraints; -- type constraints -- |
1009 |
METHODS NAMES #IMPLIED -- deprecated --'> |
1010 |
]]> |
1011 |
<!ENTITY % case.metainfo -- link metainfo for specific variant -- |
1012 |
'%mime.constraints; -- type constraints --'> |
1013 |
<!ENTITY % linkExtraAttributes |
1014 |
'%link.metainfo; |
1015 |
%case.metainfo; |
1016 |
'> |
1017 |
<![ %HTML.Recommended [ |
1018 |
<!ENTITY % key.value -- key/value pair with typed value -- |
1019 |
'NAME NAME #IMPLIED -- keyword, usually |
1020 |
required -- |
1021 |
VALUE CDATA #IMPLIED -- default value -- |
1022 |
%mime.constraints; -- type constraints |
1023 |
for value --'> |
1024 |
]]> |
1025 |
<!ENTITY % key.value -- key/value pair with typed value -- |
1026 |
'NAME CDATA #IMPLIED -- keyword, usually required -- |
1027 |
VALUE CDATA #IMPLIED -- default value -- |
1028 |
%mime.constraints; -- type constraints for |
1029 |
value --'> |
1030 |
|
1031 |
<!-- Embed and Related Elements --> |
1032 |
|
1033 |
<!ELEMENT EMBED - - (PARAM*, CAPTION?, EMBED.BODY, CREDIT?)> |
1034 |
<!ATTLIST EMBED |
1035 |
%attrs; |
1036 |
%link.internal; |
1037 |
%link.metainfo; |
1038 |
|
1039 |
Burchard and Raggett |
1040 |
Page 16 |
1041 |
|
1042 |
|
1043 |
|
1044 |
Compound Documents in HTML |
1045 |
|
1046 |
|
1047 |
%case.metainfo; |
1048 |
%size; -- size of reserved area -- |
1049 |
%align; -- alignment or float -- |
1050 |
%SDAPREF; '<Fig><Xref IDRef="#AttVal(SRC)"><?SDATrans |
1051 |
Embed: #AttList>' |
1052 |
%SDASUFF; '</Fig>' |
1053 |
> |
1054 |
<!ELEMENT CAPTION - - (%text;)+ -- caption for floating element --> |
1055 |
<!ATTLIST CAPTION |
1056 |
%attrs; |
1057 |
%align; -- side of rectangle where |
1058 |
caption placed -- |
1059 |
%SDAPREF; "Caption: " |
1060 |
> |
1061 |
<!ELEMENT EMBED.BODY O O %A.content> |
1062 |
<!ATTLIST EMBED.BODY |
1063 |
%attrs; |
1064 |
> |
1065 |
<!ELEMENT CREDIT - - (%text;)* -- copyright/credit for embedded |
1066 |
object --> |
1067 |
<!ATTLIST CREDIT |
1068 |
%attrs; |
1069 |
%SDAFORM; "Fn" |
1070 |
> |
1071 |
|
1072 |
<!-- Link Specializer Elements --> |
1073 |
|
1074 |
<!ELEMENT INPUT - O EMPTY -- builds retrieval specializer -- > |
1075 |
<!ATTLIST INPUT |
1076 |
%attrs; |
1077 |
%key.value; -- key and MIME-typed value -- |
1078 |
TYPE %InputType #IMPLIED -- defaults to TEXT in |
1079 |
FORM context -- |
1080 |
CHECKED (CHECKED) #IMPLIED -- initial boolean state -- |
1081 |
SRC %URI; #IMPLIED -- embedded graphic for |
1082 |
TYPE=IMAGE -- |
1083 |
%align.simple; -- alignment for TYPE=IMAGE -- |
1084 |
SIZE CDATA #IMPLIED |
1085 |
MAXLENGTH NUMBER #IMPLIED |
1086 |
%SDAPREF; "Input #AttVal(Type): " |
1087 |
> |
1088 |
<!ELEMENT PARAM - O EMPTY -- builds presentation specializer -- > |
1089 |
<!ATTLIST PARAM |
1090 |
%attrs; |
1091 |
%key.value; |
1092 |
%SDAPREF; "<?SDATrans Param: #AttList>" |
1093 |
> |
1094 |
|
1095 |
<!-- Corrections --> |
1096 |
|
1097 |
<!ELEMENT FORM - - %body.content -(FORM) +(INPUT|SELECT|TEXTAREA)> |
1098 |
<!ATTLIST FORM |
1099 |
%attrs; |
1100 |
ACTION CDATA #IMPLIED |
1101 |
METHOD (%HTTP-Method) GET |
1102 |
ENCTYPE %Content-Type; "application/x-www-form-urlencoded" |
1103 |
%SDAPREF; "<Para>Form:</Para>" |
1104 |
%SDASUFF; "<Para>Form End.</Para>" |
1105 |
|
1106 |
Burchard and Raggett |
1107 |
Page 17 |
1108 |
|
1109 |
|
1110 |
|
1111 |
Compound Documents in HTML |
1112 |
|
1113 |
|
1114 |
> |
1115 |
|
1116 |
|
1117 |
7. Transition Issues |
1118 |
|
1119 |
7.1. Sun's APPLET Element |
1120 |
|
1121 |
Sun's <APPLET> element [9] can be mapped to <EMBED> with essentially |
1122 |
just a few name changes: |
1123 |
|
1124 |
* APPLET becomes EMBED |
1125 |
|
1126 |
* NAME becomes ID |
1127 |
|
1128 |
* CODE is prefixed with CODEBASE to become SRC |
1129 |
|
1130 |
* CODEBASE is not needed (the embedding API is required to pass |
1131 |
the retrieval URI (the SRC) to the media handler, from which the |
1132 |
CODEBASE can be deduced) |
1133 |
|
1134 |
It is possible to construct peculiar examples where the CODEBASE is |
1135 |
not the base URI of the combination of CODEBASE with CODE, but this |
1136 |
seems more confusing than useful. |
1137 |
|
1138 |
7.2. Netscape's Early Implementations of EMBED |
1139 |
|
1140 |
Netscape initially implemented <EMBED> as an empty element [10], not |
1141 |
a container. While this causes some forward-compatibility problems, |
1142 |
the %A.content content model of <EMBED.BODY> allows error recovery |
1143 |
to occur after the first paragraph break when </EMBED> is omitted. |
1144 |
|
1145 |
Netscape's initial implementation also uses arbitrary attributes to |
1146 |
pass parameters. In the interim, authors can use a combination like |
1147 |
the following for compatibility (though it's still not legal SGML): |
1148 |
|
1149 |
|
1150 |
<EMBED SRC="sample.app" ALT="simple alt text" FOO=3 BAR=9> |
1151 |
<PARAM NAME=foo VALUE=3> <PARAM NAME=bar VALUE=9> |
1152 |
</EMBED> |
1153 |
|
1154 |
|
1155 |
8. Security Considerations |
1156 |
|
1157 |
Immediate invocation of link without user feedback or control |
1158 |
aggravates security problems of links described in [11]. |
1159 |
|
1160 |
9. Acknowledgments |
1161 |
|
1162 |
Dave Raggett did a lot of the early work on <FIG> [12] which is |
1163 |
reflected here in <EMBED>. |
1164 |
|
1165 |
Arthur van Hoff of Sun Microsystems designed <APPLET> based on |
1166 |
discussion in the hotjava-interest mailing list. This proposal has |
1167 |
|
1168 |
Burchard and Raggett |
1169 |
Page 18 |
1170 |
|
1171 |
|
1172 |
|
1173 |
Compound Documents in HTML |
1174 |
|
1175 |
|
1176 |
been strongly influenced by the <APPLET> tag. |
1177 |
|
1178 |
Dan Connolly began work to formalize the Web model [13]. Discussions |
1179 |
with Larry Masinter and Gavin Nicol were also important in shaping |
1180 |
the model presented here. |
1181 |
|
1182 |
10. References |
1183 |
|
1184 |
1. T. Berners-Lee and D. Connolly, HTML 2.0, RFC 1866. |
1185 |
|
1186 |
2. J. Postel, Internet Media Types, RFC 1590. |
1187 |
|
1188 |
3. R. Fielding, Relative Uniform Resource Locators, RFC 1808. |
1189 |
|
1190 |
4. F. Yergeau, G. Nicol, G. Adams, and M. Duerst, HTML |
1191 |
Internationalization. |
1192 |
|
1193 |
5. N. Borenstein and N. Freed, MIME Content Types, RFC 1521. |
1194 |
|
1195 |
6. T. Berners-Lee, Universal Resource Identifiers, RFC 1630. |
1196 |
|
1197 |
7. T. Berners-Lee, R. Fielding, and H. F. Nielsen, HTTP/1.1. |
1198 |
|
1199 |
8. Larry Masinter et al., Form-Based File Upload in HTML, RFC 1867. |
1200 |
|
1201 |
9. Sun Microsystems, APPLET Element Syntax. |
1202 |
|
1203 |
10. Netscape Communications, Netscape Navigator 2.0 Feature |
1204 |
Descriptions |
1205 |
|
1206 |
11. T. Berners-Lee, L. Masinter, and M. McCahill, Uniform Resource |
1207 |
Locators, RFC 1738. |
1208 |
|
1209 |
12. Dave Raggett, HTML3 Draft. |
1210 |
|
1211 |
13. Daniel W. Connolly, Resource Discovery and Reliable Links. |
1212 |
|
1213 |
11. Authors' Addresses |
1214 |
|
1215 |
|
1216 |
|
1217 |
Paul Burchard |
1218 |
<burchard@cs.princeton.edu> |
1219 |
Computer Science Dept. |
1220 |
Princeton University |
1221 |
35 Olden Street |
1222 |
Princeton NJ 08544 |
1223 |
|
1224 |
|
1225 |
|
1226 |
Dave Raggett |
1227 |
<dsr@w3.org> |
1228 |
World Wide Web Consortium |
1229 |
|
1230 |
Burchard and Raggett |
1231 |
Page 19 |
1232 |
|
1233 |
|
1234 |
|
1235 |
Compound Documents in HTML |
1236 |
|
1237 |
|
1238 |
Massachusetts Institute of Technology |
1239 |
545 Technology Square |
1240 |
Cambridge MA 02139 |
1241 |
|
1242 |
|
1243 |
|
1244 |
|
1245 |
|
1246 |
|
1247 |
|
1248 |
|
1249 |
|
1250 |
|
1251 |
|
1252 |
|
1253 |
|
1254 |
|
1255 |
|
1256 |
|
1257 |
|
1258 |
|
1259 |
|
1260 |
|
1261 |
|
1262 |
|
1263 |
|
1264 |
|
1265 |
|
1266 |
|
1267 |
|
1268 |
|
1269 |
|
1270 |
|
1271 |
|
1272 |
|
1273 |
|
1274 |
|
1275 |
|
1276 |
|
1277 |
|
1278 |
|
1279 |
|
1280 |
|
1281 |
|
1282 |
|
1283 |
|
1284 |
|
1285 |
|
1286 |
|
1287 |
|
1288 |
|
1289 |
|
1290 |
|
1291 |
|
1292 |
Burchard and Raggett |
1293 |
Page 20 |
1294 |
|