06-minutes
73.3 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
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang='en' xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta name="generator" content="HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org" />
<title>TAG face-to-face -- 6 Mar 2007</title>
<link type="text/css" rel="STYLESHEET" href="http://www.w3.org/StyleSheets/base.css" />
<link type="text/css" rel="STYLESHEET" href="http://www.w3.org/StyleSheets/public.css" />
<link type="text/css" rel="STYLESHEET" href="http://www.w3.org/2004/02/minutes-style.css" />
<meta content="TAG face-to-face" name="Title" />
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
</head>
<body>
<p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" border="0" height="48" width="72" /></a></p>
<h1>- DRAFT -</h1>
<h1>TAG face-to-face</h1>
<h2>6 Mar 2007</h2>
<p><a href='http://www.w3.org/2001/tag/2007/03/06-agenda.html'>Agenda</a></p>
<p>See also: <a href="http://www.w3.org/2007/03/06-tagmem-irc">IRC log</a></p>
<h2><a name="attendees" id="attendees">Attendees</a></h2>
<div class="intro">
<dl>
<dt>Present</dt>
<dd>Dan, Henry, Norm, Noah, Raman, Rhys, Stuart, Tim, (Dave by phone)</dd>
<dt>Regrets</dt>
<dd>Ed</dd>
<dt>Chair</dt>
<dd>Stuart</dd>
<dt>Scribe</dt>
<dd>Rhys</dd>
</dl>
</div>
<h2>Contents</h2>
<ul>
<li><a href="#agenda">Topics</a>
<ol>
<li><a href="#item01">agenda review</a></li>
<li><a href="#item02">Administrivia</a></li>
<li><a href="#item03">Approve minutes of 26 Feb 2007</a></li>
<li><a href="#item04">Next face-to-face</a></li>
<li><a href="#item05">Peer-to-Peer</a></li>
<li><a href="#item06">New Members, Charter Review, Purpose and Direction</a></li>
<li><a href="#item07">Issues list</a></li>
<li><a href="#item08">Self-describing web</a></li>
<li><a href="#item09">XBL2 and xml:id</a></li>
<li><a href="#item10">Self Describing Web, Elaborated Infoset</a></li>
<li><a href="#item11">Reports on Web Services Workshop</a></li>
</ol>
</li>
<li><a href="#ActionSummary">Summary of Action Items</a></li>
</ul>
<hr />
<div class="meeting">
<h3 id="item01">agenda review</h3>
<p class='phone'>stuart reviews the agenda</p>
<p class='phone'>noah points out that dave won't be available until later and suggests that we do Henry's item first</p>
<p class='phone'>Stuart describes the work he's done trying to organise themes for the tag and reviewing the issues list</p>
<p class='phone'><cite>TVR:</cite> we might want to finish a little later today than tomorrow</p>
<p class='phone'><cite>SW:</cite> That is the plan.</p>
<p class='phone'><cite>TimBL:</cite> we should remember that we've had a year of doing rather fragmented things and we should try and be more focussed on getting text out and pulling things together.</p>
<h3 id="item02">Administrivia</h3>
<p class='phone'>Regrets from Dave Orchard but hoping to be here via phone/shared whiteboard</p>
<p class='phone'>Regrets also from Ed Rice</p>
<h3 id="item03">Approve minutes of 26 Feb 2007</h3>
<p class='irc'><<cite>ht_mit</cite>> <a href="http://lists.w3.org/Archives/Public/www-tag/2007Feb/0029.html">http://lists.w3.org/Archives/Public/www-tag/2007Feb/0029.html</a></p>
<p class='phone'>Minutes duely approved</p>
<h3 id="item04">Next face-to-face</h3>
<p class='phone'><cite>SW:</cite> proposal for next face to face is May 30 to Jun 1</p>
<p class='irc'><<cite>DanC_lap</cite>> " I propose that</p>
<p class='irc'><<cite>DanC_lap</cite>> we schedule our next F2F meeting 30th May-1st June 2007 in the San</p>
<p class='irc'><<cite>DanC_lap</cite>> Francisco Bay Area with apologies to Henry."</p>
<p class='irc'><<cite>DanC_lap</cite>> TVR has volunteered to host</p>
<p class='phone'><cite>TVR:</cite> would like to confirm today to be able to sort logistics</p>
<p class='phone'><cite>NM:</cite> points out that there are limits on flights from SF eastwards for US and Europe</p>
<p class='phone'><cite>SW:</cite> points out that earlier in the week is difficult because of public holidays</p>
<p class='phone'><cite>HT:</cite> points out that he has a family conflict but may well be able to attend</p>
<p class='phone'><cite>TVR:</cite> asks whether we need 3 days for the meeting or not</p>
<p class='phone'><cite>NM:</cite> we need to be able to resolve this now because of flight bookings</p>
<p class='phone'>There is some willingness for some people to stay longer</p>
<p class='phone'>Stuart proposes the 30th to the 1st</p>
<p class='irc'><<cite>DanC_lap</cite>> 2.5 days works for me</p>
<p class='phone'>Discussion about the availability of flights. Proposal to start as early as possible to get the most value from the third day</p>
<p class='phone'><cite>TVR:</cite> points out that it is easy to start at 8 and that we can have breakfast during the meeting</p>
<p class='phone'>No dissent</p>
<p class='phone'>Resolved to meet May 30th to June 1st</p>
<p class='irc'><<cite>DanC_lap</cite>> half day on 1 Jun</p>
<p class='phone'><cite>NW:</cite> What about dates beyond that</p>
<p class='phone'><cite>SW:</cite> TimBL has proposed a two day meeting in Southampton in September<br />
... Dave has a preference to avoid the Monday</p>
<p class='phone'><cite>TimBL:</cite> I have a meeting that is scheduled for the Wednesday. I could look at it.</p>
<p class='phone'><cite>SW:</cite> we'll come back to that one<br />
... reviews notes taken during calls with TAG members. Suggests using this as a basis for reflection.<br />
... invites Henry to comment on recent peer to peer meeting</p>
<p class='phone'><cite>HT:</cite> Peer to peer has come up a number of times in previous discussions about TAG work<br />
... Similar questions to web services. Is peer to peer part of the web. Does webarch need to be changed to accomodate it<br />
... maybe its outside the web. I don't have a particular opinion on this.<br />
... invite to MS cambridge was because they are doing lots of things around peer to peer and they would like to know the answer to that question too<br />
... which aspects of the Old Fashioned Web are appropriate for peer to peer</p>
<p class='phone'><cite>TVR:</cite> Looking at lots of things like bit torrent and others, the mechansims are outside the web, but the discovery and publishing is via HTTP</p>
<p class='phone'><cite>NM:</cite> That suggests that we do have a role in aspects of peer to peer.</p>
<p class='phone'><cite>TimBL:</cite> We do have a role in looking for the potential cracks between different aspects. Supports doing things on the fringes. Supports the idea of doing peer to peer specifically.<br />
... HTTP should go in a peer to peer direction.</p>
<p class='phone'><cite>NM:</cite> I want the links to work as expected. I don't expect to need to supply information about the user agent to use</p>
<h3 id="item05">Peer-to-Peer</h3>
<p class='irc'><<cite>ht_mit</cite>> <a href="http://www.ltg.ed.ac.uk/~ht/p2p_notes.html">http://www.ltg.ed.ac.uk/~ht/p2p_notes.html</a></p>
<p class='irc'><<cite>Zakim</cite>> DanC_lap, you wanted to agree with TVR that p2p is orthogonal to some point, with 2 exceptions: (1) naming, (2) who gets to say what's the right answer to a get/fetch</p>
<p class='irc'><<cite>Zakim</cite>> timbl, you wanted to sy that lookibg at things on the fri nges of web acrh is important, and very much support P2P as a topic.</p>
<p class='phone'><cite>DC:</cite> where it interacts with web architecture are naming who gets to say what the answer is when you do a fetch</p>
<p class='phone'><cite>VQ:</cite> : not only can you discover what you want on peer to peer, but also there can be web-based interaction to perform additional function while you are accessing the peer to peer content<br />
... Boundary between peer to peer and web is more difficult to establish than for, say, bit torrent. Streamed TV is a good example.</p>
<p class='phone'><cite>HT:</cite> These are my notes of meetings with individuals. Goes through them</p>
<p class='irc'><<cite>DanC_lap</cite>> re uplink bandwidth... and universities... NAT vs IPV6?</p>
<p class='irc'><<cite>timbl</cite>> HT: No, NAT is not an issue, it is uplink bw</p>
<p class='phone'><cite>HT:</cite> p2p needs to be more like the OFW with respect to proxies, chunking. There are special purpose proxies that capture and redistribute content.</p>
<p class='irc'><<cite>timbl</cite>> OFW = Old-Fashioned Web, it seems</p>
<p class='phone'><cite>HT:</cite> encryption defeats this.</p>
<p class='irc'><<cite>DanC_lap</cite>> hmm... encryption... again, IPV6 gets in the way?</p>
<p class='phone'><cite>HT:</cite> Lot's of metadata, but not standardised, so can't be shared. No interest in sharing metadata</p>
<p class='phone'><cite>TVR:</cite> Privacy is one reason why this doesn't happen</p>
<p class='phone'><cite>HT:</cite> p2p support is built in to Windows XP and later<br />
... There are legitimate reasons for encryption, beyond hiding the fact that copyright material is being exchanged</p>
<p class='phone'><cite>SW:</cite> The industry might want to protect its content by encryption</p>
<p class='phone'><cite>TimBL:</cite> This happened in the satellite industry when uplinks used to be in the clear. Once peopole discovered how to access the feeds, encryption was used to protect them</p>
<p class='phone'><cite>HT:</cite> There are security issues during legitimate p2p. There are possible attacks, including DoS.</p>
<p class='irc'><<cite>DanC_lap</cite>> the name "sybil" attack makes sense to me, in the context of "Sally Field gives an outstanding award-winning performance as Sybil, a disturbed young woman who suffers from multiple personality behavior." <a href="http://movies.yahoo.com/movie/1800124802/info">http://movies.yahoo.com/movie/1800124802/info</a></p>
<p class='phone'><cite>HT:</cite> There are multiple ways of structuring torrents, including ones based on random numbers</p>
<p class='phone'><cite>TimBL:</cite> Akamai works in a similar way</p>
<p class='phone'><cite>HT:</cite> Clients can be download only, which is antisocial</p>
<p class='phone'><cite>TimBL:</cite> But some places don't have the bandwidth for upload</p>
<p class='irc'><<cite>DanC_lap</cite>> ("the venice project" and "joost" are synonyms in my brain. Am I conflating distinct things?)</p>
<p class='phone'><cite>HT:</cite> That is one of the issues with the Venice project.</p>
<p class='phone'><cite>VQ:</cite> It's 300 megabytes per hour, which is ok within regular ADSL</p>
<p class='phone'><cite>HT:</cite> Admits a misunderstanding on the numbers<br />
... Hashes are an issue for security on p2p</p>
<p class='phone'><cite>DanC:</cite> Elaborates that old PCs can be employed for collaborating in caching</p>
<p class='phone'><cite>TimBL:</cite> This works for particular communities</p>
<p class='phone'><cite>DanC:</cite> LOCKSS Lots of Copies Keeps Stuff Safe<br />
... LOCKSS is operations research. How to do the caching with low maintenance</p>
<p class='irc'><<cite>timbl</cite>> The whole desigtn assumes that a set of agents are collaborating to gain the benefit of sharing resources, but this sort of things tends not to work for one global comunity including very diverse people, like teens and libraries. I have not seen systems which make communities first class objects with explict commitment and membership.</p>
<p class='phone'><cite>HT:</cite> LOCKSS assumes that noone is doing the sybil attack and reducing the value</p>
<p class='irc'><<cite>Noah</cite>> Mentioning Oceanstore (<a href="http://oceanstore.cs.berkeley.edu/).">http://oceanstore.cs.berkeley.edu/).</a> Seems similar insofar as it's (I think) a giant peer-to-peer store in the sky, similar in that it has some sort of Byzantine agreement rather than central admin, different (I think) in that it's not fundamentally a front end to the Web, but a store of its own. You know when you're putting things into Oceanstore. All this is based on my vague recollections
of what I heard about the project.</p>
<p class='phone'><cite>HT:</cite> Last block problem is that most people who are downloading anything obscure are also downloading it. Most don't have all of the file you want. Not last chronologically, the last that completes the file for you.<br />
... There is a solution based not on the blocks that you have, but on linear combinations</p>
<p class='phone'><cite>NM:</cite> It's spread spectrum for p2p</p>
<p class='phone'><cite>HT:</cite> There is no way to request a range from current cache implementations. It's in HTTP 1.1, but implementations don't (?)<br />
... Could be useful to be able to query cache metadata.</p>
<p class='phone'><cite>SW:</cite> interesting concept for something that is meant to be transparent</p>
<p class='phone'><cite>TVR:</cite> Could be that there is no way to query what is in the cache</p>
<p class='phone'><cite>HT:</cite> No way to identify specific blocks within a file</p>
<p class='phone'><cite>TVR:</cite> Donkey (?) does use URNs for identifying blocks.</p>
<p class='phone'><cite>HT:</cite> eMule is similar</p>
<p class='phone'><cite>TVR:</cite> This has been working well for a few years</p>
<p class='phone'><cite>TimBL:</cite> HTTP URIs have an owner you can go back to, and this is useful. It would be nice to have a p2p system that supports the social system where people own URIS</p>
<p class='phone'><cite>TVR:</cite> It's possible for multiple versions of a resource to differ very slightly differently but by using the MD5 hash as a block identifier, you can still get the right block</p>
<p class='phone'><cite>NM:</cite> In certain contexts, MD5 is a tradeoff.</p>
<p class='phone'><cite>HT:</cite> p2p and HTTP get are both pull mechanisms. Should be able to have them cooperate.<br />
... If blocks had names, then an HTTP get would be able to retrieve blocks.<br />
... If it's not in the cache, the name must be able to let the cache locate the data necessary<br />
... Could traditional caches be elaborated to switch into p2p mode for some set of names at least<br />
... Need to be able to do the equivalent of virtual hosting to host things that you don't own. Looks like that is not currently possible because of NAT and port 80 limits</p>
<p class='phone'><cite>TVR:</cite> Could envisage a world where p2p is actually the way that the internet works.</p>
<p class='phone'><cite>HT:</cite> that is the way some people would like to see things develop</p>
<p class='phone'><cite>DanC:</cite> What about the point Tim raised about community</p>
<p class='phone'><cite>TVR:</cite> If you let the p2p graph technology do its thing, you get the caching for free</p>
<p class='phone'><cite>SW:</cite> We've gone quite deep</p>
<p class='phone'><cite>HT:</cite> One line left - Apache already have a module to convert HTTP get of very large files into p2p</p>
<p class='phone'>dorchard joins by phone</p>
<p class='phone'><cite>TimBL:</cite> I've heard that there is an extension that will fall back to something like bit torrent for large files</p>
<p class='phone'><cite>HT:</cite> So not just a server side component but also needs a piece in the client too</p>
<p class='irc'><<cite>dorchard</cite>> what kind of protocol operation do they use to get chunks of the file?</p>
<p class='phone'><cite>TimBL:</cite> Assumption is that the only place to look for the missing pieces is the community of people who are also looking for the same stuff<br />
... I'd be interested in solutions based on the hypertext graph</p>
<p class='irc'><<cite>timbl</cite>> Secifically, that if a n HTTP request fails then one can try the referer as a nexttry, for caching or seeding or metadaata leading to these.</p>
<p class='phone'><cite>SW:</cite> I'd like to go through the notes I had from discussing things with the TAG members.</p>
<h3 id="item06">New Members, Charter Review, Purpose and Direction</h3>
<p class='phone'><cite>SW:</cite> Technical Agenda - desire to get long standing issues finished.<br />
... Big topics - extensibility and versioning, tag soup integration, mixed languages composition<br />
... Semantic web, web services (one web or two), mobile,<br />
... Comment on tag soup situation persisting could be damaging to the web/w3C. One way of addressing this might be a set of best practice guides, if authored quickly<br />
... We will make things easier if there is a clear focus and direction<br />
... is TAG role to get ahead of the game or clear up the issues left by work of other groups<br />
... Last time, the AWWW was the 'drum beat' for TAG work. Is there another rec track item that could provide that again?<br />
... Not clear that TAG findings have an impact. Are we being ignored?</p>
<p class='irc'><<cite>DanC_lap</cite>> thanks, stuart, for doing the rounds of calls.</p>
<p class='phone'><cite>SW:</cite> Should we be concensus driven, and is this barring us from being controversial?</p>
<p class='phone'><cite>HT:</cite> Don't remember being held up by the need for concensus</p>
<p class='phone'><cite>NM:</cite> Could be that more recently there has not been so much of an issue</p>
<p class='phone'><cite>SW:</cite> Like the consensus approach and thinks its viable for such a small group<br />
... invites comments about TAG going forward</p>
<p class='phone'><cite>TVR:</cite> Want to see more findings and communicating what we do to a wider audience</p>
<p class='phone'><cite>NW:</cite> Would like to see more focus and is optimistic about how things may go</p>
<p class='phone'><cite>NM:</cite> We're much closer to having some happy goal than 2 years ago. Worth trying, but we shouldn't force a new goal where it's not ready to be done.<br />
... If setting a big goal helps us get individual items done, that's great<br />
... It's ok to be a bit ahead, or a bit behind, but shouldn't be too far<br />
... We are the architecture group, and part of our role is to highlight architectural principles to people<br />
... Should keep looking for architecture</p>
<p class='phone'><cite>HT:</cite> Hard to find out what the TAG is working on and why it's important</p>
<p class='irc'><<cite>DanC_lap</cite>> (re "what's hot", I'm interested in a 'planet tag' blog aggregator)</p>
<p class='phone'><cite>HT:</cite> There are two documents on which I'm blocked. Mode of operation has been to assign findings to specific people and the rest review. We should change to behaving more like a working group for at least some findings.</p>
<p class='phone'><cite>TVR:</cite> Agrees</p>
<p class='phone'><cite>NM:</cite> Agrees</p>
<p class='phone'>Other people indicated agreement</p>
<p class='phone'><cite>DanC:</cite> Language evolution stuff is particularly interesting and appropriate for the TAG</p>
<p class='irc'><<cite>Noah</cite>> I think it's not just more links on our home page, I think we could do a home page that really is a gateway for people learning about Web architecture and about what we as a group do. It should be a destination that, for certain purposes, people seek out.</p>
<p class='irc'><<cite>Noah</cite>> Right now, I think it's a necessary evil to get through it on the way to some bit of information.</p>
<p class='irc'><<cite>Noah</cite>> Who knows, maybe there's a Web Arch web site as well as a Web Arch finding?</p>
<p class='irc'><<cite>Raman</cite>> The other problem in explaining TAG work is that thanks to our date-based URI scheme (which i dislike immensely) everything we do looks like it was done in 2001.</p>
<p class='phone'><cite>VQ:</cite> Need more help for people to find out what we are doing and what's important. We don't expect the entire community to be directly interested in our work. TAG is mainly focused on W3C working groups</p>
<p class='irc'><<cite>Raman</cite>> I actually got asked this with respect to the finding I authored last year for example -- gist: "this looks like something from 2001, "</p>
<p class='phone'><cite>VQ:</cite> Not sure what our public face should be and it involves work</p>
<p class='irc'><<cite>Noah</cite>> Raman, I think if we have the right Web site, fewer people will be looking at the URIs, and more will be working through, e.g. our page on naming or identifying things on the Web. That could give high level tuturial, with links to the finding in context. We could have a page on XML-related issues, etc.</p>
<p class='phone'><cite>VQ:</cite> We have too many individual issues open and it's hard to prioritise and then get the momentum for progress</p>
<p class='irc'><<cite>DanC_lap</cite>> (hmm... do I hear that the TAG wants to design a web site? oh my. let's make a rock band instead. the politics are simpler.)</p>
<p class='phone'><cite>VQ:</cite> Maybe it is time to look at another rec track document. Gives a single document whose progress can be followed.</p>
<p class='phone'><cite>DO:</cite> Lots of the comments were interesting and appropriate. I've been working on three findings currently. Hoping to finish two of those by the end of my TAG stint<br />
... Would like the TAG to be slightly ahead and slightly behind in specific areas, as Noah said.</p>
<p class='irc'><<cite>Noah</cite>> I think I'm feeling the TAG should be somewhat ahead, perhaps significantly ahead on core architectural issues, generally "behind" in helping to notice the architectural implications gleaned from codifying good practice.</p>
<p class='phone'><cite>DO:</cite> Peer to peer, wireless etc, are potential areas where we could be a bit ahead. Doing some findings in more of a WG style is also a good idea.<br />
... Some findings are potentially very large topics and so there are lots of ways to go with a finding. That can imply a very different audience for the finding.<br />
... Leads to churn in documents as potential audience changes.</p>
<p class='irc'><<cite>DanC_lap</cite>> (another point, re wider and wider audiences, is that in an attempt to please everybody, the document becomes mediocre for everybody and excellent for noone)</p>
<p class='phone'><cite>DO:</cite> Need to get back into the mode of writing and reviewing more regularly</p>
<p class='irc'><<cite>dorchard</cite>> TAG blog -> TAG wiki :-)</p>
<p class='phone'><cite>TimBL:</cite> Endorse lots of the comments about getting the message out, Brochure + Blog could satisfy this kind of thing. Brochure why important, blog for what's hot</p>
<p class='irc'><<cite>DanC_lap</cite>> (I tried to get the TAG to use a wiki in the beginning. maybe the time is right now? I'd sure like to try semantic mediawiki)</p>
<p class='phone'><cite>TimBL:</cite> We used to work on classification of the issues. We seem to have lost that. Defining the relationships will also help us get on the same page.<br />
... One of the most important things we do is to pull together the bits of work done within W3C and between W3C and OMA - Quilt analogy, but more than 2D<br />
... It's time for work on the Semantic Web. Because it's more rigorously defined there is a stronger framework in which to ask and answer the questions.<br />
... Socially, I find it difficult to know how much to push for things and how much to sit back. Actually, same for everyone.<br />
... Think the group has worked well, and that that is likely to continue.<br />
... Hope I can convince the group that if we do Semantic web, I can convince the group that semantic web is an important piece of work for the TAG</p>
<p class='phone'><cite>TVR:</cite> Would like to try and get a stucture/classification to help Stuart</p>
<p class='irc'><<cite>DanC_lap</cite>> break 'till xx:25</p>
<p class='phone'><cite>NM:</cite> Advocates continuing this discussion after a break, perhaps tomorrow.</p>
<p class='irc'><<cite>Stuart</cite>> Dave... if you are there joining the virtual room might be help full <a href="https://www.rooms.hp.com/attend/default.aspx?key=EHLACVJXJ5">https://www.rooms.hp.com/attend/default.aspx?key=EHLACVJXJ5</a></p>
<p class='irc'><<cite>Stuart</cite>> Others.... you should be able to join too.</p>
<h3 id="item07">Issues list</h3>
<p class='phone'><cite>SW:</cite> Projects the issues list.</p>
<p class='irc'><<cite>DanC_lap</cite>> (TVR, I think your idea of talking about a table of contents for a document is a good one to mix into this discussion of the issues list)</p>
<p class='phone'><cite>SW:</cite> The issues list is long and it was hard to reconstruct the context. Took the dates of last discussion to try and identify those that were 'fallow'</p>
<p class='phone'><cite>TVR:</cite> Even as we look at the list, where things are marked as complete, we should review whether or not the results have been disseminated appropriately<br />
... There are documents hanging around in findings, but no context.</p>
<p class='phone'><cite>TimBL:</cite> Is there some pointer to 'what should I read to find the best information on a particular topic'.</p>
<p class='phone'><cite>DanC:</cite> We've also had the situation where we had made a decision but that we knew we had not connected with the appropriate community<br />
... What would be the desired outcome?</p>
<p class='phone'><cite>TVR:</cite> I'd like people to be able to find the information via, say, a Google search</p>
<p class='phone'><cite>DanC:</cite> Do you know how the community would formulate the query?</p>
<p class='phone'><cite>TVR:</cite> Not sure, but it seems that the TAG is the last place the community would look</p>
<p class='phone'><cite>NM:</cite> What about 'Architecture the Web Site'. More outreach. Maybe based on the AWWW document.<br />
... If it were done well, could be every reason for the community to visit it.</p>
<p class='phone'><cite>TimBL:</cite> The DIG group web site and the WSRI web site could be linked. It's a new site so could take advice from the TAG.</p>
<p class='phone'><cite>NM:</cite> we should have a better web site for the TAG<br />
... We should also have a site that is about the web architecture.</p>
<p class='phone'><cite>TimBL:</cite> Making our web presence Architecture not TAG is right.</p>
<p class='phone'><cite>TVR:</cite> We're coming at the same thing from two directions. We were talking about a compendium before the break and a site now. I view these as the same.</p>
<p class='phone'><cite>SW:</cite> Returning to the issues list, I also 'tagged' the items with 'themes'</p>
<p class='phone'><cite>TVR:</cite> Should we discuss the ones that are active?</p>
<p class='phone'><cite>SW:</cite> That's where I'm going. (Reviews the list and points out the catagorisation)</p>
<p class='phone'><cite>TimBL:</cite> Inactive in the list means what?</p>
<p class='phone'><cite>SW:</cite> We don't appear to have done anything substantial recently.<br />
... It looks like new issues get a lot of discussion.</p>
<p class='phone'><cite>TVR:</cite> Also looks like older things sometimes morph into something else</p>
<p class='phone'><cite>TimBL:</cite> The AWWW document work helped us concentrate on getting the appropriate items moved on</p>
<p class='phone'>TVR projects an editor buffer ready to create a table of contents to guide structure of TAG work</p>
<p class='phone'>Group editing ensues</p>
<p class='irc'><<cite>dorchard</cite>> I don't see the doc :-(</p>
<p class='phone'><cite>NM:</cite> are we trying to make a TOC that would make sense to a reader, or a way to organise our work</p>
<p class='phone'><cite>TVR:</cite> The former</p>
<p class='phone'><cite>NM:</cite> It looks to me more like the latter. Readers need a different organisation</p>
<p class='phone'><cite>TimBL:</cite> I suspect that we'll find that the TOC this time around will look a lot like we had last time<br />
... If we find that we can allocate section numbers from the existing AWWW then we should decide to do a version 2 of that document</p>
<p class='phone'><cite>NM:</cite> I agree.</p>
<p class='phone'><cite>HT:</cite> where is our defence of http the scheme fit?<br />
... We have a draft finding called URN's and registries, which has become use http:.</p>
<p class='phone'>TVR adds it to the section on Naming.</p>
<p class='phone'><cite>SW:</cite> Is there a major topic on applications?</p>
<p class='phone'><cite>NM:</cite> I agree</p>
<p class='phone'><cite>SW:</cite> That includes things like how to define URI spaces</p>
<p class='phone'><cite>TVR:</cite> There is a piece of this about making restful sites etc.<br />
... We could do this based on some existing application, like one from Google where these things are considered during design.</p>
<p class='phone'><cite>NM:</cite> We seem don't seem to be saying anyting about futures here.</p>
<p class='phone'><cite>TVR:</cite> I disagree that all we are only talking about is the 'old web'. The same old issues apply to new usages</p>
<p class='irc'><<cite>dorchard</cite>> TAG needs to produce youTube videos?</p>
<p class='irc'><<cite>Stuart</cite>> <a href="http://www.youtube.com/watch?v=6gmP4nk0EOE&eurl=">http://www.youtube.com/watch?v=6gmP4nk0EOE&eurl=</a></p>
<p class='phone'><cite>TimBL:</cite> On the whiteboard I've tried out a way of organising topics algorithmically. It is the upper half of an n-dimensional matrix</p>
<div class="image">
<a href="http://www.flickr.com/photos/skw/417817389/"
><img src="http://farm1.static.flickr.com/187/417817389_e4c378585c_d.jpg"
alt="Whiteboard image" /></a></div>
<p class='phone'><cite>DanC:</cite> It's a good QA check</p>
<p class='phone'><cite>TVR:</cite> where does security come up</p>
<p class='phone'><cite>DO:</cite> It comes up everywhere. People encode information in payload to ensure it's secure</p>
<p class='irc'><<cite>timbl</cite>> 1. URI</p>
<p class='irc'><<cite>timbl</cite>> 2 HTTP</p>
<p class='irc'><<cite>timbl</cite>> 2.1 HTTP URI</p>
<p class='phone'><cite>DanC:</cite> This cross cutting idea could be a way to deal with volume 2. Includes mobile, security, accessibility, internationalisation,</p>
<p class='irc'><<cite>timbl</cite>> etc</p>
<p class='phone'>TVR adds a new section to the TOC</p>
<p class='phone'><cite>NM:</cite> Suggests that there is an opportunity to look at use cases</p>
<p class='phone'><cite>DanC:</cite> Can we include massive interactive on-line games</p>
<p class='phone'>TVR e-mails the current view of the TOC to the TAG list</p>
<p class='phone'><cite>TVR:</cite> One way to slice this would be to use the cross cutting chapter as the applications chapter<br />
... Could also pick a concrete application and discuss the issues in that context<br />
... It's like turning it upside down.</p>
<p class='phone'><cite>SW:</cite> Can we place the issues into the TOC?</p>
<p class='phone'><cite>TVR:</cite> I'd be happy to try and do that</p>
<p class='phone'>Placing issues within the TOC ensues</p>
<p class='phone'><cite>HT:</cite> We need to remember that for particular communities the issues we have are the most important things that they are worrying about</p>
<p class='phone'><cite>NM:</cite> Should we have sections that address concepts that people actually regularly use, like site, document etc.</p>
<p class='phone'><cite>TVR:</cite> I asked a question about whether we are dealing with dynamic applications. With Web 2.0, the retrieved representation changes over time - the 'loading ...' example for a page being created dynamically</p>
<p class='phone'><cite>HT:</cite> I found that there wasn't a term for the thing that the user agent represents and the user interacts with</p>
<p class='phone'>RL points out that there are some definitions that are in the DI Glossary</p>
<p class='phone'><cite>HT:</cite> That could be useful, but these are things that need to be in the Web arch glossary</p>
<p class='phone'>Group adds a number of independencies as cross cutting concerns.</p>
<p class='phone'><cite>DanC:</cite> I was thinking about agents for change and dampers on change as cross cutting concerns</p>
<p class='phone'><cite>SW:</cite> Can we get a list of those that are teetering on the brink of completion</p>
<p class='irc'><<cite>Raman</cite>> toc23.html is on the Web site, will need the readable bit set.</p>
<p class='irc'><<cite>Raman</cite>> DanC, could you set the perms bit?</p>
<p class='irc'><<cite>DanC_lap</cite>> will do...</p>
<p class='phone'><cite>SW:</cite> What do we do with the TOC next?</p>
<p class='irc'><<cite>DanC_lap</cite>> fyi, Raman , you can set the ACL yourself at <a href="http://www.w3.org/2001/tag/doc/toc23.html">http://www.w3.org/2001/tag/doc/toc23.html</a>,access</p>
<p class='phone'><cite>RL:</cite> Hanging the issue list items into the toc seems like a good next step</p>
<p class='irc'><<cite>DanC_lap</cite>> there. it's 200 now.</p>
<p class='phone'><cite>TVR:</cite> How about Stuart and I working on proposals about where to hang the open, active issues within the TOC</p>
<p class='irc'><<cite>timbl_</cite>> <a href="http://www.amazon.com/Master-Commander-Side-World-Widescreen/dp/B0001HLVS2/ref=pd_bbs_sr_1/102-1903036-8371356?ie=UTF8&s=dvd&qid=1173205978&sr=1-1">http://www.amazon.com/Master-Commander-Side-World-Widescreen/dp/B0001HLVS2/ref=pd_bbs_sr_1/102-1903036-8371356?ie=UTF8&s=dvd&qid=1173205978&sr=1-1</a></p>
<h3 id="item08">Self-describing web</h3>
<p class='irc'><<cite>DanC_lap</cite>> ScribeNick: DanC_lap</p>
<p class='irc'><<cite>Rhys</cite>> <a href="http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html">http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html</a></p>
<p class='phone'>NM recaps history of "self-describing web" discussion in the TAG back to EDI 1.5years ago</p>
<p class='phone'><cite>NM:</cite> punch line: simple story about self-description...<br />
... you always need some rules to interpret something...<br />
... even with paper documents, there's the alphabet, left-to-right conventions, ...<br />
... and that way, what the author intended gets conveyed. [?]<br />
... then, focussing on the web, since communication is not just point-to-point, but where readers are encouraged to explore documents not written specifically to them...<br />
... if the contents of the web aren't we labelled, we don't communicate well.<br />
... Then I was talking with Dan, and he said "yes, that's the simple part, but the more interestinig bit is dynamically picking up new terms via URIs"<br />
... so now... we could pick over the text, but perhaps it's better to review goals: what does "self-describing web" mean to various tag members?<br />
... [something connected to xmlFunctions that I missed]<br />
... then I heard from tim... [ rdf... owl ...]<br />
... and one sense of self-describing web is to extract RDF from XML and HTML, a la GRDDL. [?]</p>
<p class='phone'><cite>DanC:</cite> there's (1) the case for standards, and (2) the story of how to introduce a new format, using widely-deployed html/http/uris + natural-language + programming languages</p>
<p class='phone'><cite>TimBL:</cite> we told a story in webarch about how to get from a URI thru the stack of specs, to what the URI refers to</p>
<p class='phone'><cite>replay:</cite></p>
<p class='phone'>[13:44] <timbl_> q+ to suggest that the self-descibing document is one part of the architecture story which is a mapping from URI to intehet. It is the part in which the representation relates to intent. What is specifically interesting is the way you can boostrap yourself into find the necessary stuff indirectly eg through namespace document lookup.</p>
<p class='irc'><<cite>Stuart</cite>> timbl queued to say "to suggest that the self-descibing document is one part of the architecture story which is a mapping from URI to intehet. It is the part in which the representation relates to intent. What is specifically interesting is the way you can boostrap yourself into find the necessary stuff indirectly eg through namespace document lookup."</p>
<p class='phone'><cite>DanC:</cite> the case for standards is shared between email and the Web, but email doesn't have the lookup mechanism for new MIME types, by design. IANA is _the_ registry of MIME types for email.</p>
<p class='irc'><<cite>Zakim</cite>> raman, you wanted to say that limit to machine readability/follow-your-nose -- not "communicate to human"</p>
<p class='phone'><cite>TimBL:</cite> the recursive bootstratp nature is the interesting bit</p>
<p class='phone'><cite>TVR:</cite> this stuff about communicating "the same thing" seems somewhat of a distraction from the self-describing web story; it brings in styling etc., for one thing<br />
... the interesting bit is the dynamic software configuration stuff, so that you can deploy new stuff in the web and it "just works"</p>
<p class='phone'><cite>DO:</cite> the dynamic discovery is the interesting story to tell; let's not spend too much space/time on the static/shared background</p>
<p class='phone'>[or something like that]</p>
<p class='phone'><cite>DO:</cite> I have heard a few examples/use cases of [darn; leaked out]. RDDL... [darn; missed examples; help?]</p>
<p class='irc'><<cite>Stuart</cite>> ex1: xml doc->namespace(s)->RDDL....</p>
<p class='phone'><cite>DO:</cite> perhaps contrast with stuff that's not self-describing, e.g. microformats. where do we look up class="fn" without a URI?<br />
... another counter-example is some urn schemes, a la the urns/registries finding</p>
<p class='irc'><<cite>Zakim</cite>> ht_mit, you wanted to mention "follow your nose"</p>
<p class='phone'><cite>HT:</cite> I want this finding to explain "view source" (ack Tim Bray) and "follow your nose (ack DanC)</p>
<p class='irc'><<cite>timbl_</cite>> "View Source" is very much human beings lookng things up. "Follow your nose" is most often done by machines.</p>
<p class='phone'><cite>HT:</cite> this should answer in detail "what do I have to know ahead of time to look at the Oxaca weather report?"<br />
... there are 3 things you need to be able to look up:<br />
... (1) the charset from the Content-Type header, iso8859-1 or utf-8</p>
<p class='phone'>HT notes complex discussion of definitive sources of charset info</p>
<p class='phone'><cite>SKW:</cite> is that stuck?</p>
<p class='phone'><cite>HT:</cite> well, I have seen some progress, but it's been a year since the last progress point, so maybe time to rethink<br />
... this is 3023bis, replacing "there is no fragid semantics for XML" with a ref to XPointer, and capturing negotiations about charset</p>
<p class='phone'><cite>TimBL:</cite> and XML ids?</p>
<p class='phone'><cite>HT:</cite> XPointer refers to xml ids in a way that agrees with specs that have come later</p>
<p class='phone'><cite>NDW:</cite> XPointer says "if it's of type ID..." and the xml:id spec says "xml:id is of type ID", so the pieces fit</p>
<p class='phone'>TimBL raises a deployment question/issue about xml:id ...</p>
<h3 id="item09">XBL2 and xml:id</h3>
<p class='phone'>is there a last call comment or issues list item or something that captures the XBL2/xml:id thing, please?</p>
<p class='phone'>aha... "163. Last call comments on XML Binding Language (XBL) 2.0"</p>
<p class='irc'><<cite>timbl_</cite>> | I have marked your request as a potential formal objection.</p>
<p class='irc'><<cite>timbl_</cite>> I doubt that it will come to that, but thank you for leaving the door</p>
<p class='irc'><<cite>timbl_</cite>> open. I will ask the WGs for whom I reviewed the document if they feel</p>
<p class='irc'><<cite>timbl_</cite>> strongly enough about the issue to make that objection.</p>
<p class='phone'>ah... ok... "I haven't heard any compelling arguments why XBL should spell it "id"."</p>
<p class='phone'><cite>TVR:</cite> [missed... about xml:id and ID...]</p>
<p class='phone'><cite>TimBL:</cite> I gather the XBL implementors have a table, by namespace, of which attributes are of type ID</p>
<p class='irc'><<cite>Zakim</cite>> DanC_lap, you wanted to advocate more study of traditional theory of language, e.g. monotonicity</p>
<p class='irc'><<cite>Noah</cite>> I still think the hierarchical view is more important than we're admitting. It does, however, make things like XPointer very hard, because it presumably wants to use tree semantics blindly without really checking the semantics of the ancestors.</p>
<p class='phone'><cite>DanC:</cite> pass; I'll come back to that at a better time, perhaps</p>
<p class='irc'><<cite>timbl_</cite>> apparently IIRC the architecture was that the attr which had type ID was kept as afunction of element namespace, so svg would map to xml:id</p>
<p class='irc'><<cite>timbl_</cite>> but that set of people may not have implemented it</p>
<p class='irc'><<cite>Zakim</cite>> dorchard, you wanted to respond to Noah that there are some commonalities across failures.</p>
<p class='phone'><cite>DO:</cite> [missed some...] I think this points out a problem with the W3C process...<br />
... by analogy, consider my company and weblogic server and some stuff layered on it...<br />
... a customer wants the new stuff...</p>
<p class='irc'><<cite>Raman</cite>> for the record, we discovered the problem caused by xml:id not being present as we were going last call on XForms and writing test suites -- we suddenly discovered that we couldn't tell whether an id was an id when getting xml instances from foreign namespaces</p>
<p class='phone'><cite>DO:</cite> [missed some]... so what you do is decide to be a platform provider, so you hold off on the layered stuff until the platform is ready</p>
<p class='phone'>tx, Raman ; I was having trouble scribing.</p>
<p class='irc'><<cite>Zakim</cite>> DanC_lap, you wanted to advocate using CR to do 2-phase commit to sync dependencies</p>
<p class='phone'><cite>DanC:</cite> e.g. perhaps we should have held XML 1.1 at CR until XML Schema and XML 1.1 were better integrated</p>
<p class='phone'><cite>NM:</cite> consider a container format like SOAP...<br />
... oops; putting 2 existing documents in one might introduce ID clashes<br />
... on the one hand, it would be nice to have XMLFunction-style opaque boundaries around parts of the tree; on the other hand, that makes XPointer ID implementation impractical.</p>
<p class='irc'><<cite>dorchard</cite>> Any modularity spec, like xinclude, wsd:include, etc. have the same ID clash problem.</p>
<p class='phone'><cite>NM:</cite> I stipulate namespaces doesn't fix the SOAP combination problem. [?]</p>
<p class='phone'><cite>TVR:</cite> yes, which is why XML Core created xml:id</p>
<p class='irc'><<cite>timbl_</cite>> (that doesn't help the container problem)</p>
<p class='phone'><cite>HT:</cite> one of the reasons [this draft] is very limited, is that it's _only_ about getting at the infoset, not at only higher level app semantics...<br />
... I'm concerned that you read the document otherwise.<br />
... control goes top-down, but composition is bottom up. [he said it better than that]<br />
... quoting interacts OK with id in the story I told, since quoting [bleah. what he said made sense, but it has leaked out.]<br />
... and I like the limited "elaborated infoset" scope</p>
<p class='phone'>some groaning about not going further...</p>
<p class='phone'><cite>TVR:</cite> if we can capture that much, it's a valuable contribution</p>
<p class='irc'><<cite>Zakim</cite>> timbl_, you wanted to note has just made a good case for the LackOfQuotingInXML-nnn issue</p>
<p class='phone'><cite>TBL:</cite> this points out a limitaion of XML, that you can't nest XML documents arbitrarily<br />
... if there's a duplicate id, what does #theid refer to?</p>
<p class='phone'><cite>HT:</cite> the 1st one. the spec is subtle but clear</p>
<p class='phone'>HT reads from a spec; scribe requests a pointer/excerpt</p>
<p class='phone'><cite>HT:</cite> note XML Schema has a scoped identity constraint mechanism</p>
<p class='phone'>(I wonder if XPointer supports it)</p>
<p class='phone'><cite>NM:</cite> the tough point is integrating XPointer with those constraints</p>
<p class='irc'><<cite>Zakim</cite>> Noah, you wanted to say I >want< XML functions to be about semantics</p>
<p class='phone'><cite>NM:</cite> OK, so the scope of the draft is more clear to me now. thanks.</p>
<p class='irc'><<cite>ht_mit</cite>> NM, DC -- no, XPointer does _not_ currently offer any way of pointing to things courtesy of their XML Schema-assigned Identities</p>
<p class='phone'><cite>NM:</cite> but 90% of the time, the right way to design XML languages is to exploit the hierarchy in the applicaiton semantics<br />
... [NM exceeds scribe's bandwidth, approaches timbl-speed ;-]</p>
<p class='irc'><<cite>Raman</cite>> added elaborating infoset to language section of toc23</p>
<p class='phone'><cite>NM:</cite> I think telling the recursive semantics story is a very interesting goal.</p>
<p class='irc'><<cite>timbl_</cite>> xml:quote="true"</p>
<p class='irc'><<cite>Noah</cite>> Why bother to namespace qualify quote? :-)</p>
<p class='irc'><<cite>Noah</cite>> In the interest of trying to help the scribe, what I said (or tried to say) was:</p>
<p class='phone'><cite>TimBL:</cite> I'm interested in looking at the costs and benefits of using xml:id in XBL2, both at the XBL2 scope and in a wider scope</p>
<p class='irc'><<cite>Zakim</cite>> Norm, you wanted to point out unforseen uses</p>
<p class='irc'><<cite>Noah</cite>> I understand that there is value in doing what Henry says he's done, which is to push out the easy part of the story first. That's Infoset elaboration. Fine.</p>
<p class='irc'><<cite>Noah</cite>> On the other hand, I think the 90/10 case should be that the semantics of the XML document should be recursive. I think that's a really, really interesting story to tell, and particularly important to my view of self-describing Web.</p>
<p class='irc'><<cite>Noah</cite>> Use case: a word processor application with persistent undo. The user edits the document, and a it changes, the word processor stores in a subtree in its XML file fragments of the XML that it will need to restore iff the users issues an "undo".</p>
<p class='irc'><<cite>Noah</cite>> To understand that the deleted content is not logically in the document, you have to recursively understand the semantics of first the root element, then the children, down to the one that says <savedUndoStuff>, which will tell you the implications of having that content there.</p>
<p class='irc'><<cite>Noah</cite>> Let's admit that generalized features like XPointer are unlikely to respect that, but the recursive semantics are crucially important to the self describing web.</p>
<p class='irc'><<cite>Noah</cite>> Bottom line: I hope Henry won't stop with the self-elaborating infoset, but will go all the way to recursive semantics of XML documents.</p>
<p class='irc'><<cite>Noah</cite>> We now rejoin our regularly scheduled xml:id debate.</p>
<p class='phone'><cite>TVR:</cite> the questions I'd look at: Is XBL2 designed as an XML family language for use not only in browsers, or...<br />
... is it just for browsers and just happens to use angle brackets</p>
<p class='phone'><cite>NM:</cite> do you see it as black-and-white? or are there degrees?</p>
<p class='phone'><cite>TVR:</cite> well, I can see grey areas, but I see a pretty important black-and-white question.</p>
<p class='phone'><cite>Rhys:</cite> I bet it depends on who you ask. If you ask the XBL authors, they'll answer that it's just for browsers, but if you ask others, e.g. DI WG, they'll say they want to integrate it with other XML stuff</p>
<p class='irc'><<cite>Zakim</cite>> timbl_, you wanted to say: I think XBL2 is a generic XML langauge in the sense that it is in XML and will be edited and fetched, but it isn'y in the sense that it doesn't have</p>
<p class='phone'><cite>TBL:</cite> yes, in some ways XBL2 is generic XBL. They're not applying for a mime type, ...<br />
... because it's not the sort of thing you'd attach in a mail message or follow a link to, except links when the context is clear. [!]</p>
<p class='phone'><cite>TVR:</cite> then why does CSS have a mime type?</p>
<p class='phone'><cite>TimBL:</cite> to distinguish it from, e.g. XSLT, in HTTP conneg<br />
... everything needs a mime type; the XBL2 folks are happy using a generic XML mime type, since they don't expect dedicated viewers</p>
<p class='phone'><cite>DanC:</cite> the practicing community doesn't know that CSS has a mime type; 99.99% of it is served as text/plain, I think.<br />
... and it still works.</p>
<p class='phone'><cite>TVR:</cite> see earlier discussion of outreach/communication/presentation of TAG output</p>
<p class='irc'><<cite>Noah</cite>> Well, if generic tools like Google search did something truly valuable with CSS that's correctly typed, and not with other CSS, we'd start seeing people take the trouble to type the content.</p>
<p class='irc'><<cite>Zakim</cite>> DanC_lap, you wanted to point out untested hooks are evil</p>
<p class='phone'><cite>DanC:</cite> so doing a mime type for XBL2 without implementation experience seems iffy</p>
<p class='phone'><cite>NDW:</cite> doesn't webarch say "you should get a MIME type"?</p>
<p class='phone'><cite>DO:</cite> in a couple WGs, the *only* reason we did a MIME type is so we could say how fragids work.</p>
<p class='phone'>[that seems like a plenty good reason...</p>
<p class='phone'><cite>scribe:</cite> I was afraid you were going to say "the only reason we got a mime type was cuz webarch said we should"]</p>
<p class='phone'><cite>NM:</cite> [missed... something about +xml ...]. Maybe application/xml + namespaces is enough in lots of cases</p>
<p class='phone'><cite>TVR:</cite> yes, we should work on this mess around namespaces, mime types, and profiles</p>
<p class='irc'><<cite>Zakim</cite>> dorchard, you wanted to re-emphasize the point about self-describing in media types.</p>
<p class='phone'><cite>DO:</cite> yes, about this self-describing web stuff... as TVR says, it's pretty broken...<br />
... e.g. I wonder how much better things would be if the SOAP media type had more richness to it.</p>
<p class='irc'><<cite>Stuart</cite>> hmmmm.... a media type param with a URI for what is wrappped?</p>
<p class='phone'><cite>DO:</cite> e.g. application/purchase-order+soap [?]<br />
... so yes, let's work on this area</p>
<p class='phone'><cite>TVR:</cite> DO just covered one half/part; another part is CDF: how does it combine components using different media types?</p>
<p class='irc'><<cite>timbl_</cite>> <> a PurchaseOrder. PruchaseOrder rdfs:ubClassOf SoapDocument. SoapDocumnt rdfs:subClassOf XMLDocument. XMLDocument subvclasOf TextDocument.</p>
<p class='irc'><<cite>Zakim</cite>> DanC_lap, you wanted to inform stuart that I tried a mime type that delegates to URI space, but the IETF reviewer declined it</p>
<p class='phone'><cite>TVR:</cite> to see what's in a document... how much is in the mime type label vs buried in namespaces</p>
<p class='irc'><<cite>timbl_</cite>> TextDocument rdfs:subClassOf OctetSequence.</p>
<h3 id="item10">Self Describing Web, Elaborated Infoset</h3>
<p class='phone'>-> <a href="http://www.w3.org/2001/tag/doc/elabInfoset.html">http://www.w3.org/2001/tag/doc/elabInfoset.html</a> The elaborated infoset: A proposal Henry S. Thompson 30 Jan 2007</p>
<p class='phone'>(hmm. the semi-formalism in the infoset spec bugs me. Now that we have XQuery and RDF specs with lots of running code and test suites, can we please use one of them?)</p>
<p class='phone'>HT summarizes discussion history and abstracts the document</p>
<p class='phone'><cite>HT:</cite> is this an accurate summary of what we talked about last time?<br />
... and is this the right enumeration of enumerating namespaces? there are 3: include, encrypt, signature</p>
<p class='phone'><cite>TVR:</cite> what about iframe?</p>
<p class='phone'><cite>TimBL:</cite> I'm concerned with "before any application-specific processing is attempted"<br />
... I think the TAG issue is about all semantics, not just infoset semantics<br />
... I much prefer the 2nd phrasing: "if an author takes responsibility for the information in an XML document, exactly what is s/he taking responsibility for?"<br />
... xinclude is nice in that you can express it as a function of *only* the infoset, but that's a special case. iframe's semantics include manipulating pixels</p>
<p class='phone'><cite>TVR:</cite> only pixels? there's DOM stuff too...</p>
<p class='phone'><cite>TimBL:</cite> umm.... is the iframe actually replaced in the DOM? isn't there a separate DOM?</p>
<p class='phone'><cite>TVR:</cite> anyway, xinclude isn't that different from iframe, is it?</p>
<p class='phone'><cite>TimBL:</cite> xinclude can be expressed purely as an infoset manipulation; iframe cannot</p>
<p class='irc'><<cite>timbl_</cite>> if an author takes responsibility for the information in an XML document, exactly what is s/he taking responsibility for?</p>
<p class='phone'><cite>NM:</cite> I still have concerns about attaching elaborating semantics to namespaces. I prefer to use elements as the hook.<br />
... i.e. qualified names</p>
<p class='irc'><<cite>timbl_</cite>> I agree with NM anout that that tit should be 'elaborating elements' not 'elborating namespaces'</p>
<p class='phone'><cite>HT:</cite> I think it would be a strange design to have an elaborating element in a namespace along with other stuff.<br />
... the signals are still elements and attributes...</p>
<p class='phone'><cite>NM:</cite> then it's over-determined to attach semantics to namespaces</p>
<p class='phone'><cite>HT:</cite> I could maybe go either way; my preference is as written</p>
<p class='irc'><<cite>timbl_</cite>> TBL agrees with NM</p>
<p class='phone'><cite>NM:</cite> the reason I think this is more than a coin-flip is that communities like NVDL are giving semantics to namespaces, and I'd rather not endorse that</p>
<p class='irc'><<cite>Zakim</cite>> Norm, you wanted to ask if Tim means that a new spec should assert that it belongs to the "top down, self-describing" class.</p>
<p class='phone'><cite>TBL:</cite> no, I mean for it to apply to all XML</p>
<p class='phone'><cite>NDW:</cite> that's false; witness XSLT<br />
... literal result element</p>
<p class='phone'>TimBL explains how to look at the XSLT literal result example as an HTML document that has an elaborating gizmo in the paragraph, which elaborates to an em</p>
<p class='phone'><cite>NM:</cite> the HTML spec says that this is a document with a paragraph with an ignored thingy in it...<br />
... or maybe it depends on the media type</p>
<p class='phone'><cite>TimBL:</cite> there's an error recovery view of it, but the <xsl:value-of > element has a qualified name...</p>
<p class='irc'><<cite>Zakim</cite>> DanC_lap, you wanted to note this sort of detailed design critique sounds like a "yes" answer to HT's question of whether he's in the right ballpark and to ask that we consider a</p>
<p class='irc'><<cite>Noah</cite>> Right. What I'm saying is, there are two general architectures to choose from: I) A namespace is (roughly) a collection of names, each of which has whatever semantics. Often, but not necessarily, the names from a given namespace are designed to be used together. -or- II) namespaces have a semantic, or at least, you've got to signal in advance which namespaces have the characteristic that some of their names are used in ways that carry unusual semantics (e.</p>
<p class='phone'><cite>TimBL:</cite> indeed, a <script> that sticks an h1 outside its part of the tree is not a function; it's a procedure with side effects</p>
<p class='irc'><<cite>Noah</cite>> I strongly favor (I), and I'm concerned that the draft finding on elaborating infosets is not the only place I see people making assumption (II). Possible future TAG work merited?</p>
<p class='phone'>TBL modifies the html literal result element, so that it's a purchase order document...</p>
<p class='phone'><cite>scribe:</cite> unlike p, whose spec tells you [something1],</p>
<p class='phone'>(scribe is struggling; if this were a WG design discussion, I'd interrupt to make sure we get this example in the test suite. but we're not, so I won't.)</p>
<p class='phone'><cite>HT:</cite> yes, I'm willing to try taking "elaborating namespaces" out. I don't think "namespaces have semantics "is broken but it's not a battle I want to pick.<br />
... while I stipulate to Norm's point that non-compositional XML languages are possible, Tim's position appeals to my experience that people seem to almost always make compositional languages<br />
... I presented a compositional explanation of SVG etc, and I got an "oh no; that doesn't work" at the backplane workshop</p>
<p class='phone'>TBL points out some issue about XBL/SVG or something. [help?]</p>
<p class='phone'><cite>HT:</cite> I heard [Chris?] say "there is no domain in which you can model the semantics of HTML/CSS/SVG in a compositional way"<br />
... I'm not certain I understand the argument, but his experience is considerable</p>
<p class='irc'><<cite>timbl_</cite>> I think tere may be cases when my idea of the 'semantic may be less concrete than Henry's, Maybe be parameterized by say window width say.</p>
<p class='irc'><<cite>Noah</cite>> scribenick: noah</p>
<p class='phone'><cite>HT:</cite> Can we wrap by popping to metaquestion: stipulate that I will remove the implication that namespaces have semantics, and will also make clear this is part of a larger and as yet incomplete project, which is whether all of XML is compositional.</p>
<p class='phone'><cite>SW:</cite> What's the larger goal not achieved?</p>
<p class='phone'><cite>HT:</cite> Doesn't say that in general, and strongly recommended in future, the application semantics of XML documents is/should be compositional.</p>
<p class='phone'><cite>DC:</cite> Can't you get there by deleting from this document?</p>
<p class='phone'><cite>HT:</cite> No. Well, result would be vacuous?</p>
<p class='phone'><cite>TBL:</cite> Have we said that the way to interpret the Namespace at the top?</p>
<p class='phone'><cite>HT:</cite> No.</p>
<p class='phone'><cite>NM:</cite> I hope Tim meant the qualified name of the root element.</p>
<p class='phone'><cite>TBL:</cite> Anyway, if we haven't said it's determined by what's at the top, we can't tell the story.</p>
<p class='phone'><cite>HT:</cite> Not convinced.<br />
... In the strict story, XML documents get semantics via the Infoset. You don't interpret the angle brackets and equals signs directly.<br />
... It's what's available via the Infoset.<br />
... Thus, every statement about XML document must be in the following: "The semantics of an xml element namespace=x and localname=y is whatever.<br />
... What this little document is addressing, except in odd cases like writing an editor, this talks about "the Infoset" you're starting with.</p>
<p class='phone'><cite>TBL:</cite> There's the mistake. There is not necessarily "an" Infoset. You recursively ask about the root.<br />
... You can't in generally look through things and know when to do the elaboration.</p>
<p class='phone'><cite>HT:</cite> We fundamentally disagree. Never mind, we agree completely.<br />
... There are probably two ways to understand this, mine is perhaps more naive but easier to communicate.<br />
... I like to think in 3 steps. Each is functional, so you can compose them, and get the story.</p>
<p class='phone'>TBL and NM: No, you can't get Tim's story.</p>
<p class='phone'><cite>HT:</cite> Step 1, parse character sequence to produce vanilla infoset. Step 2 elaborates, to get elaborate that infoset. Step 3 application semantics.<br />
... What is semantics of <xi:include href="notMeButHim.hmtl"/><br />
... I think the semantics of the elaborated infoset.</p>
<p class='irc'><<cite>Stuart</cite>> is this depth first v breadth first?</p>
<p class='phone'><cite>TBL:</cite> Example of a document modeling pay per view. Scribe thinks there are two subtrees, one of which is guarded by a did you pay for it element?<br />
... Whether to elaborate depends on whether user pays the money.<br />
... Your model, Henry, involves picking up all the movies, and paying for them, first.<br />
... In general, you have to do elaboration, to down.</p>
<p class='phone'><cite>HT:</cite> Taking that view gives you a more complicated model for no functional distinction.</p>
<p class='irc'><<cite>Rhys</cite>> ack :</p>
<p class='irc'><<cite>Zakim</cite>> :, you wanted to say that there is a real example of a markup language that does what TimBL just described</p>
<p class='phone'><cite>HT:</cite> What <quote> is for, is to keep the movies to be elaborated.</p>
<p class='phone'><cite>TBL:</cite> It's not just a quote.</p>
<p class='phone'><cite>HT:</cite> The reason you quote is because you're not ready to elaborate yet.</p>
<p class='irc'><<cite>Zakim</cite>> Noah, you wanted to talk about consistent use of certain QNames vs. prepass</p>
<p class='irc'><<cite>timbl_</cite>> NM: I think there is a coheernebt view of [,...] which make this work ... the spec sould say that one way o using xml:include is as a root element -- for example HTML could say that when xml:include is the root element then it should be elaborated.</p>
<p class='irc'><<cite>timbl_</cite>> TBL: If xml:include specifies that every xml:inckldue unstace in a document MSU be elborTED THEN THERE IS A BUG.</p>
<p class='irc'><<cite>timbl_</cite>> ooops</p>
<p class='irc'><<cite>timbl_</cite>> must be elaborated then there is a bug</p>
<p class='phone'><cite>NM:</cite> I think the spec for xi:include should say what it means as an application semantic if you use me as a root element and/or if my ancestor does not override my semantic</p>
<p class='irc'><<cite>Norm</cite>> timbl_, that *is* what the XInclude spec says</p>
<p class='phone'><cite>HT:</cite> I'm now convinced that Tim and I cannot for now be satisfied by the same design.</p>
<p class='phone'><cite>TVR:</cite> Try a new tack. Henry has spoken of pipelines and recursion. Let's consider, for comparison, LISP S expressions. When you write a recursive descent parser, you have two simple rules, which are to read head then tail of list, and a quoting mechanism to override the default.<br />
... That's what appealed to me originally from Henry's design. The problem I have is that if we allow an element at some depth to change the quoting process, that's somewhat troubling.<br />
... Feels weird to change how you're reading down the tree.<br />
... Something from reading <a:foo> should not be allowed to change quoting characteristics of a descendent <b:foo></p>
<p class='phone'><cite>RL:</cite> I think there may be real XML markups that would break if all XIncludes were pre-expanded. E.g. di:select, probably VoiceXML, and also probably SMIL.<br />
... It has conditionals.</p>
<p class='phone'><cite>HT:</cite> Conditionals are a good example, because they are quoted.<br />
... In the pure lambda calculus you have to quote with the only available mechanism which, perversely, is lambda.<br />
... In LISP, as opposed to lambda calculus, COND has special characteristics. It's not a function, it's a "special form".<br />
... The arguments are implicitly quoted, so we can decide to only evaluate some of them.<br />
... What's true in Scheme, but not in Interlisp, the only special forms are built into the language. In Interlisp, you could define N-Lambdas (spelling?), in which you could define your own functions with implicit argument quoting.<br />
... I'm arguing, by analogy, for the Schema-like approach.<br />
... On this analogy, Tim's position would be the Interlisp position.</p>
<p class='phone'><cite>SW:</cite> Do we have enough to proceed?</p>
<p class='phone'><cite>NM:</cite> Well, we've crystalized a disagreement. :-)</p>
<p class='phone'><cite>HT:</cite> I suppose Tim and I need to think about who blinks first.</p>
<p class='irc'><<cite>DanC_lap</cite>> (I found <a href="http://www.lisp.org/HyperSpec/Body/glo_s.html#special_form">http://www.lisp.org/HyperSpec/Body/glo_s.html#special_form</a> ...)</p>
<p class='irc'><<cite>Norm</cite>> ScribeNick: Norm</p>
<p class='irc'><<cite>Noah</cite>> Workshop CFP URI: <a href="http://www.w3.org/2006/10/wos-ec-cfp.html">http://www.w3.org/2006/10/wos-ec-cfp.html</a></p>
<p class='irc'><<cite>Noah</cite>> Program: <a href="http://www.w3.org/2007/01/wos-ec-program.html">http://www.w3.org/2007/01/wos-ec-program.html</a></p>
<h3 id="item11">Reports on Web Services Workshop</h3>
<p class='irc'><<cite>Noah</cite>> Noah's TAG presentation: <a href="http://www.w3.org/2001/tag/2007/03/WSPresentation/titleSlide.html">http://www.w3.org/2001/tag/2007/03/WSPresentation/titleSlide.html</a></p>
<p class='phone'><cite>Noah:</cite> Workshop attended by on the order of 50-70 people at Mitre in Bedford last week.<br />
... Grew from an suggestion that W3C should concentrate more on Web Services and lesson SemWeb.<br />
... Workshop was an effort by the W3C and the folks using WS for enterprise applications to find out what was happening, what was needed in this area.</p>
<p class='phone'><cite>DO:</cite> I think there was a focus on finding concrete use cases weren't being met by what's in play or expected to be in play.</p>
<p class='irc'><<cite>timbl_</cite>> I think the message from the AC meeting was more along the lines of: please have more focus and expertize on enterprise computing.</p>
<p class='phone'><cite>Noah:</cite> The call for papers was very heavy on use cases, but the actual talks didn't go in that direction.<br />
... That may be the history, I'm just reporting what I heard Eric say.<br />
... The main point is that Eric was pleasantly surprised by the response.<br />
... Participants were a mix: vendors, WS-* usual suspects, a few REST supporters. Particularly interesting: there were a lot of regular users.<br />
... Workshop would have been stronger if there had been more straight users.<br />
... Big topics: what are people doing, what do people say they need, to what degree is the W3C the right place to do this, and looming behind, what is the relationship between the web and web services.<br />
... So, what are people doing?<br />
... WS-* is largely used behind the firewall for enterprise integration. Outside the firewall, it's REST based.<br />
... Citigroup disagreed, saying they had a large investment in WS-* in public.</p>
<p class='phone'><cite>DO:</cite> Yahoo Mail uses SOAP generating several million messages a week.</p>
<p class='phone'><cite>Noah:</cite> Why are people using WS-*? Tooling was one answer. People perceive that when they buy in to the WS stack, the tooling grinds out a pile of code that does it.<br />
... When they try REST, the tooling asks if they want to do a GET or a POST.<br />
... The other highlight of something needed was better support for databinding.<br />
... The tooling works well at first, but sometimes after several months you find bugs.<br />
... One of the frustrations was that not everyone was present.</p>
<p class='phone'><cite>TV:</cite> The emphasis on the tooling generates second-order bugs (bugs in the tools generate buggy gorpy code). If you look at "w"eb "s"ervices, they're writing gorpy JavaScript by hand. There must be something better.</p>
<p class='phone'><cite>Noah:</cite> Tooling really doesn't really have anything to do with WS-* vs. REST. The choices are about the same.<br />
... But the vendors have largly packaged it that way.</p>
<p class='irc'><<cite>DanC_lap</cite>> (fyi, I wrote an essay in April 1997 about this tooling stuff and distributed objects in the web... ". So one step forward in complexity management from richer interface description is two, three, or ten steps backward in total development cost." <a href="http://www.w3.org/People/Connolly/9703-web-apps-essay.html">http://www.w3.org/People/Connolly/9703-web-apps-essay.html</a> )</p>
<p class='phone'><cite>Noah:</cite> Paul Downey said it's about messaging. Messaging systems mitigate problems of "the connection dropped"</p>
<p class='phone'><cite>TV:</cite> Was there anyone asking about REST and JSON?</p>
<p class='phone'><cite>Noah:</cite> Yes, I think it was pretty well understood that there are these two approaches.<br />
... The real deeper question is should WS go away because the web is simpler/better. Some say it should, some are not convinced.<br />
... When I send a transaction to the Federal Reserve, I'm not sure I trust an http POST, I want to send it through a reliable messaging queue.<br />
... Is W3C the right place?<br />
... Some argued that the culture at W3C isn't right. Atom, for example, was done at IETF.<br />
... Others pointed out the value of reputation, IP policy, staff, etc.</p>
<p class='phone'><cite>DanC:</cite> Atom wasn't low cost...Tim Bray's dedicated time for 18 months isn't cheap.</p>
<p class='phone'><cite>Noah:</cite> People repeatedly refered to the soap builders model.<br />
... End points with test cases published quickly and a mailing list to discuss the answers.<br />
... I thought it worked very well. And it helped the W3C WGs.<br />
... One suggestion was to collapse the core specs into a single "WS Core" WG.<br />
... Try to put a box around some of this stuff as sort of stable and just fix bugs.<br />
... Ken Lasky produced some summary slides, but they don't stand alone. Hopefully he'll digest that a bit and post something.<br />
... One position is that WS just isn't the web and you shouldn't try to join them.<br />
... My view is that the web wasn't just built to integrate things that were designed to be integrated into it.<br />
... That seemed to make some sense.</p>
<p class='phone'><cite>TV:</cite> Doesn't that dichotomy remind you of the xml:id vs id discussion of earlier?</p>
<p class='phone'><cite>Noah:</cite> We did eventually settle on a use case for our paper which I think really helped illustrate the points.<br />
... I'd like to be able to get a link to my airline reservation but I'd also like to be able to send that to my travel agent and ask them to cancel it. That might require more than just http for security or whatever.</p>
<p class='phone'><cite>TV:</cite> We've had similar discussions around the mobile web. The biggest risk I see is that there's an increasing interest in carving out little disjoint spaces.</p>
<p class='phone'><cite>Noah:</cite> At the very least, there's a lot of buy in so that big systems will be built with it. So we should work with them to help tell the right stories.</p>
<p class='phone'><cite>DO:</cite> I have a bit of a different spin. I agree with a lot of what you said.<br />
... I found a couple of points very interesting. The first was that for all the discussion of web arch vs. web services arch and how to reconcile them, there was little support for any kind of technical solutions that might do that.<br />
... I pushed a little bit that perhaps WADL ought to be standardized at W3C. It barely made it onto the final ballot and there were only two votes for it.<br />
... Including mine.<br />
... And two votes against.<br />
... I really expected one or two enterprise customers to be supportive, but that didn't happen.<br />
... The flip side of that, allowing SOAP clients to bind to URIs, didn't even make it onto the ballot.<br />
... The customers simply weren't interested in a technical solutions.</p>
<p class='phone'><cite>Noah:</cite> I thought the process was a bit bizarre. We had 15 or so things but we could only vote for two. So I think WADL is a good idea, but I put my two votes elsewhere.<br />
... There was definite tension.</p>
<p class='phone'><cite>DO:</cite> I asked if the world was a better place because some of the specs had gone through the W3C?<br />
... I said I wasn't so sure, cf the endpoint references debackle.<br />
... There's tension between fast-tracking and having architectural coherence.<br />
... If we don't want architectural oversight, maybe we should just do things at OASIS and rubber-stamp away.<br />
... I also asked how is enterprise computing different from non-enterprise computing.<br />
... In enterprise computing, the applications have more faith in the well-behavedness of applications.<br />
... This means that they're more comfortable with more state in their applications.<br />
... There are also issues around security, managability, and non-functional requirements.<br />
... That raises questions about what that means for specs. There was little uptake on that.</p>
<p class='phone'><cite>Noah:</cite> Except that lots of folks said nice things about the state finding and encouraged us to finish it.</p>
<p class='phone'><cite>TV:</cite> There are very large scale applications available today that are much more robust than some enterprise apps.<br />
... Apps like gmail have been exposed to far more users than most enterprise applications.</p>
<p class='irc'><<cite>DanC_lap</cite>> (the dev cost of gmail dwarfs meat-and-potatoes enterprise stuff, I expect.)</p>
<p class='phone'><cite>TV:</cite> When you talk enterprise apps, one important distinction is that you deploy a lot more enterprise applications. You get one app at GM and a very similar, but not quite the same, application at Ford.</p>
<p class='phone'><cite>DO:</cite> At a Yahoo search you might have eight different parameters with zillions of users.<br />
... That means you can get away without a machine processable language.<br />
... In enterprise computing, you have far more parameters but not as many users. So you need a lot more tooling support.<br />
... The PeopleSoft application is something like 8,000 tables and 12,000 screens. You can't compare that to something like web search.</p>
<p class='phone'><cite>Noah:</cite> There are also things like reporting requirements, disaster recovery, etc. These folks are conservative.<br />
... There's going to be a mix for a long time.</p>
<p class='phone'><cite>Stuart:</cite> Pick up tomorrow with namespaceDocument-8.</p>
<p class='phone'>ADJOURNED</p>
</div>
<h2><a name="ActionSummary" id="ActionSummary">Summary of Action Items</a></h2>
<!-- Action Items -->
[End of minutes]<br />
<hr />
<address>Minutes formatted by David Booth's <a href="http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">scribe.perl</a> version 1.127 (<a href="http://dev.w3.org/cvsweb/2002/scribe/">CVS log</a>)<br />
$Date: 2007/03/12 15:29:13 $</address>
</body>
</html>