index.html
29 KB
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US"><head><title> Usage Patterns For Client-Side URI parameters
</title><style type="text/css">
code { font-family: monospace; }
div.constraint,
div.issue,
div.note,
div.notice { margin-left: 2em; }
ol.enumar { list-style-type: decimal; }
ol.enumla { list-style-type: lower-alpha; }
ol.enumlr { list-style-type: lower-roman; }
ol.enumua { list-style-type: upper-alpha; }
ol.enumur { list-style-type: upper-roman; }
div.exampleInner pre { margin-left: 1em;
margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
border-top-width: 4px;
border-top-style: double;
border-top-color: #d3d3d3;
border-bottom-width: 4px;
border-bottom-style: double;
border-bottom-color: #d3d3d3;
padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css"/></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"/></a></p>
<h1><a name="title" id="title"/> Usage Patterns For Client-Side URI parameters
</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"/>W3C Working Draft 15 April 2009</h2><dl><dt>This version:</dt><dd>
<a href="http://www.w3.org/TR/2009/WD-hash-in-uri-20090415/">
http://www.w3.org/TR/2009/WD-hash-in-uri-20090415/
</a>
</dd><dt>Latest version:</dt><dd>
<a href="http://www.w3.org/TR/hash-in-uri/">http://www.w3.org/TR/hash-in-uri/
</a>
</dd><dt>Editor:</dt><dd>T. V. Raman
<a href="mailto:raman@google.com"><raman@google.com
></a></dd></dl><p>This document is also available in these non-normative formats: <a href="hash-in-uri.xml">XML</a>.</p><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2009 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr/><div>
<h2><a name="abstract" id="abstract"/>Abstract</h2><p>Designers of URIs
have traditionally used
<code>?
</code> to encode
<em>server-side
</em> parameters. At its inception, the Web
also introduced fragment identifiers (preceded by
<code>#
</code>)
as a means of addressing specific locations in a document. As
highly interactive applications get built using Web parts (HTML,
CSS and JavaScript component resources that are themselves Web
addressible — see
<a href="#tvr-cacm2009">[tvr-cacm2009]</a>, there is an
increasing need for encoding interaction state as part of the
URI. The Web is beginning to discover and codify design patterns
based on fragment identifiers for many of these use cases.
</p><p>This draft finding is being prepared in response to
<a href="http://www.w3.org/2001/tag/group/track/issues/60"> TAG
issue #60
</a>. This document explores the issues that arise in
this context, and attempts to define best practices that help:
</p><ul><li><p>Create URIs for intermediate pages in a
Web application so that the
<em>back button does the right
thing
</em>
</p></li><li><p>Enable clients to address into
specific points in a stream of content, e.g., video.
</p></li></ul><p>The goal of this finding is to initially collect
the various usage scenarios that are leading to innovative uses
of client-side URI parameters, along with the solutions that have
been developed by the Web community. When this exercise is
complete, this finding will conclude by ensuring that these
design patterns are mutually compatible. If some of these usage
patterns are identified as being in conflict, we will recommend
best practices that help side-step such conflicts. We encourage
the wider Web community to point us at emerging usage scenarios
and design patterns so that we maximize our chances of arriving
at a final finding that helps move forward the architecture of
the Web in a self-consistent manner.
</p></div><div>
<h2><a name="status" id="status"/>Status of this Document</h2><p><em>This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of current
W3C publications and the latest revision of this technical report can be found
in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at
http://www.w3.org/TR/.</em></p><p>This document has been developed for
discussion by the
<a href="http://www.w3.org/2001/tag/">W3C
Technical Architecture Group
</a>. An earlier version, dated March 20, 2008, was made
publicly available as a draft TAG finding, but not as a formal W3C working
draft. The TAG decided at its <a href="http://www.w3.org/2001/tag/2009/04/02-minutes.html#action01">2 April
2009 teleconference</a> to publish this version as a
First Public Working Draft in order to get additional input from the
Web community. Sections that need
additional work are intentionally left as empty place-holder
sections so that the Web community gets a sense of where we would
like to take this document.</p><p>Although <a href="http://www.w3.org/2001/tag/group/track/issues/60">this
issue</a> has been under discussion within the TAG and on its <a href="http://lists.w3.org/Archives/Public/www-tag/">public discussion list</a>, publication as a Working Draft
does not imply that these discussions are complete or that the TAG has
reached consensus on recommendations in this area.</p><p>Publication as a Working Draft does not imply endorsement by the W3C Membership. This is
a draft document and may be updated, replaced or obsoleted by
other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>Please send comments on this
finding to the publicly archived TAG mailing list
<a href="mailto:www-tag@w3.org">www-tag@w3.org
</a> (
<a href="http://lists.w3.org/Archives/Public/www-tag/">archive
</a>).
</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February
2004 W3C Patent Policy</a>. W3C maintains a <a href="/2001/tag/disclosures">public list of any patent
disclosures</a> made in connection with the deliverables of the group;
that page also includes instructions for disclosing a patent. An
individual who has actual knowledge of a patent which the individual
believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
6 of the W3C Patent Policy</a>.</p></div><div class="toc">
<h2><a name="contents" id="contents"/>Table of Contents</h2><p class="toc">1 <a href="#d0e128">Introduction
</a><br/>
2 <a href="#d0e142">Use Case
Scenarios
</a><br/>
2.1 <a href="#d0e147">Addressing Into Multimedia
Streams
</a><br/>
2.1.1 <a href="#d0e202">Things To Note
</a><br/>
2.1.2 <a href="#d0e275">Extrapolating From This Pattern
</a><br/>
2.1.3 <a href="#d0e303">Architectural
Questions
</a><br/>
2.2 <a href="#d0e348">Interaction State And Browser History
</a><br/>
2.3 <a href="#d0e368">AJAX Libraries And State Management
</a><br/>
2.4 <a href="#d0e410">Web Command Lines
</a><br/>
2.5 <a href="#d0e427">Passing Data Among Frames
</a><br/>
2.6 <a href="#d0e462">The
Naked
Hash-Ref
</a><br/>
3 <a href="#d0e494">Recommended Best Practices
</a><br/>
4 <a href="#d0e499">Affected Communities To Liaise With</a><br/>
5 <a href="#d0e512">Conclusions
</a><br/>
6 <a href="#open-issues">Open Issues
</a><br/>
7 <a href="#d0e520">References
</a><br/>
</p></div><hr/><div class="body"><div class="div1">
<h2><a name="d0e128" id="d0e128"/>1 Introduction
</h2><p>At the beginning of the Web, we decided to encode
<em>server-side
</em> URI parameters with a
<code>?
</code>. At
the same time, the Web adopted
<code>#
</code> to attach fragment
identifiers to URIs so that user-agents could address into
specific locations in an HTML document. Nearly 20 years later,
the Web has built a strong set of conventions around how URI
parameters are used. As transactional applications began moving
on to the Web in the late 1990's, server-side parameters formed a
core building block for how application state was communicated
between client and server. In this phase of Web evolution,
clients were still comparatively simple, and client-side URI
parameters did not move beyond the use of fragment
identifiers. But with Web 2.0 applications increasingly moving
traditional client-side applications to the Web, we are now
seeing a variety of design patterns beginning to emerge with
respect to how client-side URI parameters are used in order to
influence client interaction. The need to remain consistent with
the prevalent Web architecture has seen these design patterns
build on the existing mechanism of fragment identifiers in
URIs. This finding enumerates the various emerging patterns along
with their associated use cases as a means of documenting
existing practice on the Web.
</p></div><div class="div1">
<h2><a name="d0e142" id="d0e142"/>2 Use Case
Scenarios
</h2><p>This section enumerates the various usage
scenarios that are leading to innovative uses of client-side URI
parameters on the Web.
</p><div class="div2">
<h3><a name="d0e147" id="d0e147"/>2.1 Addressing Into Multimedia
Streams
</h3><p>When publishing multimedia streams, there is often a need
to address into specific points in the multimedia stream, e.g.,
by using a time-index. The simplest means of doing this is to
pass in the start-time as a server-side parameter in the URI,
e.g.,
<code>http://www.example.com/media.stream?start=03:06:09
</code>
and have the server start streaming the content starting at 3
hours, 6 minutes and 9 seconds into the content. This has the
additional side-benefit of creating distinct URIs for each point
in the media stream and such URIs can be used to bookmark
locations of interest.
</p><p>It is also possible to leverage
client-side parameters encoded as part of the URI (using a
<code>#
</code>), where this
<em>pseudo
</em> fragment
identifier is used by client-side scripts as an argument to be
passed to an appropriate
<em>locator
</em> function. Consider
the following example taken from
<em>cnn.com
</em>:
</p><div class="exampleOuter"><div class="exampleInner"><pre><a href="http://www.cnn.com/video/#/video/tech/2008/02/19/vo.aus.sea.spider.ap">
Giant sea spider filmed deep underwater
</a></pre></div></div><p> CNN uses links like the above for all the topical video
segments that are published on its site. The URI in this case has
the following components:</p><table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides"><thead><tr><th>Component
</th><th>Value
</th></tr></thead><tbody><tr><td>Protocol
</td><td>http
</td></tr><tr><td>Host
</td><td>www.cnn.com
</td></tr><tr><td>Path
</td><td>video
</td></tr><tr><td>Client
Param
</td><td>#/video/tech/2008/02/19/vo.aus.sea.spider.ap
</td></tr></tbody></table><div class="div3">
<h4><a name="d0e202" id="d0e202"/>2.1.1 Things To Note
</h4><blockquote><p>The browser is expected to do a GET of the URI
leading up to the fragment, and the processing application, in
this case, the JavaScript embedded in the HTML Response processes
the portion of the URI following the
<code>#
</code>.
<br/> Note that in the general case, the JavaScript function
that eventually processes the client param may not have been
present in the original HTTP Response it may come from a
Javascript library that was loaded as the result of a subsequent
HTTP GET request as a result of a
<code>script
</code> in the
text/html response.
<br/> The fragment identifier has
been intentionally identified as a
<em>client
parameter
</em>.
<br/> Treating it as a regular
fragment identifier in this usage would result in one incorrectly
inferring that the URI for the video resource being addressed is
<code>http://www.cnn.com/video
</code>.
<br/>This would
result in all the video links on the CNN site getting the same
URI.
<br/>Thus, the entire URI in this case is
http://www.cnn.com/video/#/video/tech/2008/02/19/vo.aus.sea.spider.ap
<br/> A consumer of this URI who goes looking for an
<code>id
</code>within the
<em>Response
</em> that matches the
<code>#-suffix
</code> of this URI will fail.
<br/>The
reported
<em>Content-Type
</em> for the resource is
<code>text/html
</code>. However the behavior of the
<code>#-suffix
</code> in this case is not defined by the HTML
specification.
<br/>As used, the
<code>#-suffix
</code>
is a first-class
<em>client parameter
</em> in that it gets
consumed by a
<code>script
</code> that is served as part of the
HTML document returned by the server upon receiving a GET
request.
<br/>This embedded script examines the URI
available to it as script variable
<code>content.location
</code>,
strips off the
<code>#
</code> and uses the rest of the prefix as
an argument to function that generates the actual URI.
<br/> Having constructed this content URI, the script then
proceeds to instruct the browser to play the media at the newly
constructed location.
<br/>Notice further that the
behavior of a user-agent that does not execute the embedded
JavaScript is different given this URI. Notice further that the
HTTP Response headers do not give the client any indication that
this is likely to be so.
</p></blockquote></div><div class="div3">
<h4><a name="d0e275" id="d0e275"/>2.1.2 Extrapolating From This Pattern
</h4><p>The CNN example cited above is not unique with respect to
its use of
<code>#
</code> within the URI for encoding parameters
to the receiving application. It shows that in a world of dynamic
documents, the traditional fragment identifier need no longer be
an
<code>idref
</code> value that addresses an existing node in
the serialized HTML making up the HTTP Response. In addition to
possibly being a static
<code>idref
</code>, the fragment
identifier in the URI, the pattern demonstrated here generalizes
to the following:</p><blockquote><p>An
<code>idref
</code> to a
dynamically generated node.
<br/>A parameter to be
<em>consumed
</em> by the
<em>application
</em> that is
delivered as the HTTP Response to the original GET
request.
</p></blockquote></div><div class="div3">
<h4><a name="d0e303" id="d0e303"/>2.1.3 Architectural
Questions
</h4><p>This section enumerates some of the questions
raised by this design pattern:
</p><blockquote><p> What if the
returned HTML contains an element that has the same fragment ID
as the one being used as a client-side parameter — who
wins?
<br/>What should the correct behavior be in the
face of such conflicts? <br/> (1) To scroll down to
that element
<br/>(2) play the video
<br/>(3) Error message
<br/>(4) Do nothing?
<br/>What happens if the receiving client does
not implement JavaScript, or has had scripting turned
off?
<br/>Until now, URIs have been equally useful to
browsers and non-browser consumers. this pattern demonstrates a
case where the
<em>URI
</em> inferred by browsers vs
non-browsers is
<em>different
</em>. A non-browser that
receives a URI as in the above, and sees a
<code>Content-Type
</code> of
<code>text/html
</code> might assume
(incorrectly) that the URI for this video resource is
<code>http://www.cnn.com/video.html
</code>.
<br/> A
related fragment id meaning arises when one considers
content-negotiation. For instance:
<br/>a)
get application/rdf+xml "http://example.com/exp/#something"
<br/>b)
get text/html
"http://example.com/exp/#something"
<br/>Given that
the fragment identifier leads to a subsequent request, who should
process the error response if one should be raised by that
subsequent request?
</p></blockquote></div></div><div class="div2">
<h3><a name="d0e348" id="d0e348"/>2.2 Interaction State And Browser History
</h3><p>AKA
<em>make the back button do the right thing
</em>. For
live examples of this design pattern, see
<a href="http://mail.google.com">GMail</a> and
<a href="http://maps.google.com">Google Maps
</a> both of which take
extreme care to ensure that the
<em>back button
</em> works as
the user would expect. These applications use
<code>iframe
</code>
proxies to achieve the desired effect.
</p></div><div class="div2">
<h3><a name="d0e368" id="d0e368"/>2.3 AJAX Libraries And State Management
</h3><p>AJAX
applications use features of Dynamic HTML (DHTML) to create
highly reactive user experiences. Updates to the Web user
interface in response to user actions no longer require a full
page reload. Consequently, the user can perform a sequence of
interaction steps while remaining on the
<em>same page
</em>
at least as seen from the browser's perspective of
<code>content.location
</code>. This makes for a good user
experience, except for the following:</p><blockquote><p>Recording
key points in the interaction flow, e.g., for
bookmarking.
<br/>Providing intuitive behavior for the
browser's history mechanism.
<br/>Snapshoting
interaction state so that one can return to a partially completed
task at a later time.
</p></blockquote><p> Today, many of the details of AJAX programming have been
abstracted away by higher level toolkits such as Dojo
<a href="#dojo">[dojo]</a> and
<a href="#google-gwt">[google-gwt]</a>GWT. Management of
interaction state and browser history is one of the key
affordances implemented in these libraries. History mechanisms in
AJAX libraries like GWT and Dojo share a lot in common, and the
approach can be traced back to
<a href="http://code.google.com/p/reallysimplehistory/">Really
Simple History (RSH)
</a>. In addition, the mechanism described
here has also been adopted by a recent update to GMail.
</p><p>
The basic premise is to keep track of the application's
<code>internal state
</code> in the uri fragment identifier. This
works because updating the fragment doesn't typically cause the
page to be reloaded. This approach has several benefits:</p><blockquote><p> It's about the only way to control the browser's history
reliably.
<br/> It provides good feedback to the
user.
<br/> It's
<code>bookmarkable
</code> —
i.e., the user can create a bookmark to the current state and
save it, email it, or whatever.
</p></blockquote></div><div class="div2">
<h3><a name="d0e410" id="d0e410"/>2.4 Web Command Lines
</h3><p>When applications
can be built of Web parts, there is a need to configure them at
the point the application is launched. Traditional applications
would call these default start-up or
<em>command-line
</em>
options. We see the equivalent emerging for configuring desktop
gadgets and widgets where command-line options are passed in via
URI parameters — in this context, the URI is the Web
command-line. For one sample implementation and its associated
usage, see
<a href="http://internet-apps.blogspot.com/2007/11/using-urls-to-pass-parameters-to-web.html">Using
URLs To Pass Parameters To The Web
</a>. Dave Raggett's
<a href="http://www.w3.org/Talks/Tools/Slidy/">HTMLSlidy
</a> uses
URIs of the form
<code>...#(nn)
</code> to address into a deck of
slides.
</p></div><div class="div2">
<h3><a name="d0e427" id="d0e427"/>2.5 Passing Data Among Frames
</h3><p>Web applications that use multiple frames often need to pass
data between them. This problem gets even more interesting when
the child frame displays content from a domain different from
that of its parent. In this case, the parent and child frames do
not share any script context — that would open a cross-site
scripting hole. A common technique that is used where the parent
and child have mutually agreed to collaborate is for the parent
to pass data to the child via a fragment identifier by reseting
the child's
<code> location
</code> URI. Thus, given a parent
frame
<code>P
</code> and a child frame
<code>C
</code>, where the
location URIs
<code>U_P
</code> and
<code>U_C
</code> come from
different domains, the parent frame might pass data to the child
by resetting its location URI to
<code>U_C#data
</code>; the child
picks up this data by polling for changes in its location
URI. This technique is common in
<a href="http://en.wikipedia.org/wiki/Comet_(programming)">Comet
Programming
</a>. As an example, the
<a href="http://dojotoolkit.org/node/87">Dojo AJAX toolkit
</a>
uses an
<a href="http://www.google.com/search?&q=iframe+proxy&num=25">IFrame
proxy
</a> to enable cross-domain XML HTTP Requests. this is a
useful technique when writing cross-site mashups. As an example,
see
<a href="http://code.google.com/p/google-axsjax/wiki/Showcase">XKCD
and AxsJAX
</a> — a cross-site mashup that mashes together
XKCD comics with their associated transcripts to create a
speech-friendly XKCD experience.
</p></div><div class="div2">
<h3><a name="d0e462" id="d0e462"/>2.6 The
<em>Naked
</em> Hash-Ref
</h3><p>As the final item in the
usage scenarios
<em>as seen on the Web
</em>, this section
documents the use of a single
<code>#
</code> sign as the value of
the
<code>href
</code> attribute on HTML anchors. This can be
thought of as a
<em>relative URI
</em> with a
<em>null
</em> fragment identifier. Web sites wishing to
override the
<em>default-target
</em> behavior of anchors use
this when attaching a JavaScript event-handler to anchor elements
for mouse-clicks. The only justification to place a naked
<code>#
</code> as the value of the
<code>href
</code> attribute
appears to be to avoid anything showing up on the browser status
bar as the user activates the link. Note that this idiom also
creates significant hurdles for non-mouse users of the Web.
</p></div></div><div class="div1">
<h2><a name="d0e494" id="d0e494"/>3 Recommended Best Practices
</h2><p>This section will be populated upon completion of this finding.
Note that the preceding sections have identified design patterns without prejudice — with a view to enumerating the pros and cons of the various idioms seen on the Web today.</p></div><div class="div1">
<h2><a name="d0e499" id="d0e499"/>4 Affected Communities To Liaise With</h2><p>It is clear that we will need to liaise effectively with
standard groups that are active in defining the formats and
protocols that come together in turning an HTTP Response into an
interactive user interface for a Web application. This section
will be used to track these dependencies,
and may be removed upon final publication of this document.</p><blockquote><p>The <a href="http://www.whatwg.org">WhatWG</a> that presently defines the behavior of conforming HTML5 Web browsers in conjunction with the W3C HTMLWG.<br/>The HTTP work in the IETF.</p></blockquote></div><div class="div1">
<h2><a name="d0e512" id="d0e512"/>5 Conclusions
</h2><p>This section will be completed when this finding is ready for final publication as an officially approved TAG Finding.</p></div><div class="div1">
<h2><a name="open-issues" id="open-issues"/>6 Open Issues
</h2></div><div class="div1">
<h2><a name="d0e520" id="d0e520"/>7 References
</h2><dl><dt class="label"><a name="www-tag-archive" id="www-tag-archive"/>www-tag-archive</dt><dd>
Mail thread on WWW-TAG from 2007 that initiated some of these
discussions.
(See http://lists.w3.org/Archives/Public/www-tag/2007Jul/0148.html.)</dd><dt class="label"><a name="JsonP" id="JsonP"/>JsonP</dt><dd>
JSONP: JSON With Padding
(See http://ajaxian.com/archives/jsonp-json-with-padding.)</dd><dt class="label"><a name="wikipedia-comet" id="wikipedia-comet"/>wikipedia-comet</dt><dd> Comet Programming from Wikipedia
(See http://en.wikipedia.org/wiki/Comet_(programming).)</dd><dt class="label"><a name="sidewinder-hash" id="sidewinder-hash"/>sidewinder-hash</dt><dd>
Mark Birbeck: Using URLs To Pass Parameters To The Web
(See http://internet-apps.blogspot.com/2007/11/using-urls-to-pass-parameters-to-web.html.)</dd><dt class="label"><a name="google-gwt" id="google-gwt"/>google-gwt</dt><dd>
Google Web Toolkit — Java software development framework
that makes writing AJAX applications like Google Maps and GMail
easy for developers taking care of browser and platform
details.
(See http://code.google.com/webtoolkit/.)</dd><dt class="label"><a name="tvr-cacm2009" id="tvr-cacm2009"/>tvr-cacm2009</dt><dd> Toward 2^W
— Beyond Web-2.0, T. V. Raman, Communications Of The ACM,
ACM, New York.
(See http://portal.acm.org/citation.cfm?id=1461945.)</dd><dt class="label"><a name="dojo" id="dojo"/>dojo</dt><dd> The
Javascript Toolkit by the Dojo Foundation.
(See http://dojotoolkit.org/.)</dd></dl></div></div></body></html>