05-07-tag.html
66.1 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
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
<?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">
<head profile="http://www.w3.org/2003/g/data-view">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Basel Meeting of the W3C Technical Architecture Group, 5-7 Oct 2004</title>
<link rel="transformation" href="http://www.w3.org/2001/tag/2004/10/groktagftf.xsl" />
<style type="text/css">
h1 { text-align: center }
body { background: white; color: black }
.cancelled {color: #BEBEBE}
.overdue { background: red; color: black }
dd { margin-top: .2em }
div.minutes div { border-left: dotted; padding-left: 1em }
div.minutes div div { border-left: solid; padding-left: 1em }
div.minutes .resolved { background: green; color: white }
div.minutes .action { background: orange; color: black }
blockquote { border-left: double; padding-left: 1em; font-style: italic; text-align: justify }
address { text-align: right }
</style>
<link type="text/css" rel="stylesheet" href="/StyleSheets/base.css" />
<link />
</head>
<body>
<div><a href="../../../../">W3C</a> * <a href="../../">TAG</a> | Previous: <a
href="../09/27-tag.html">27 Sep</a></div>
<h1>TAG Meeting, 5-7 October 2004</h1>
<h2><a
href="http://lists.w3.org/Archives/Public/www-archive/2004Oct/att-0024/tag-basel-2.jpg"><img
align="right" src="tag-basel.jpg" alt="tag members on the roof in
Basel" /></a>hosted in Basel, Switzerland by <a href="http://www.day.com/">Day
Software</a></h2>
<div style="text-align: center">on this page: <a
href="#who">Participants</a> * <a href="#where">Venue</a> * <a
href="#agenda">Agenda</a> * <a href="#minutes">Minutes</a><br />
nearby: <a href="http://lists.w3.org/Archives/Public/www-tag/">www-tag
archive</a>, irc <a
href="http://www.w3.org/2004/10/05-tagmem-irc">Tue</a>, <a
href="http://www.w3.org/2004/10/06-tagmem-irc">Wed</a>, <a
href="http://www.w3.org/2004/10/07-tagmem-irc">Thu</a><br />
<small>also: fun with <a
href="http://esw.w3.org/topic/MeetingRecords">MeetingRecords</a>, <a href="http://www.w3.org/2003/g/data-view">GRDDL</a>: <a
href="groktagftf.xsl">groktagftf.xsl</a>, <a href="http://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2003%2F11%2Frdf-in-xhtml-processor&xmlfile=http%3A%2F%2Fwww.w3.org%2F2001%2Ftag%2F2004%2F10%2F05-07-tag">output</a>, <a
href="Makefile">Makefile</a>, <br /> photos by NDW: <a
href="http://lists.w3.org/Archives/Public/www-archive/2004Oct/att-0023/tag-basel-1.jpg">photo1</a>
<a
href="http://lists.w3.org/Archives/Public/www-archive/2004Oct/att-0024/tag-basel-2.jpg">photo2</a></small>
</div>
<p>The goals of the meeting are:</p>
<ul>
<li>Propose responses to <strong>all</strong> LC#2 comments</li>
<li>Progress on Issues and Findings</li>
</ul>
<p>Preparation materials include:</p>
<ul>
<li><cite><a href="http://www.w3.org/TR/2004/WD-webarch-20040816/">Architecture of the World Wide Web, 1st Edition</a></cite><br />
Last Call WD 16 Aug 2004 (2nd last call)
</li>
<li><a href="http://www.w3.org/2001/tag/webarch/">WebArch
Editor's draft</a> (esp. <a href="http://www.w3.org/2001/tag/2004/webarch-20040816/">28 Sep snapshot</a>)</li>
<li><a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/">Archive of public-webarch-comment</a>, <a href="http://www.w3.org/2001/tag/2004lc/lc-status-report.html">status report</a></li>
<li><a href="http://www.w3.org/2001/tag/issues">TAG issues
list</a></li>
</ul>
<address>
created by Stuart Williams, TAG co-chair<br />
minutes by Dan Connolly<br />
with thanks to the scribes: Noah Mendelsohn, Norm Walsh, Chris Lilley, Tim Berners-Lee, Roy Fielding, Paul Cotton<br />
<small>$Revision: 1.38 $ of $Date: 2004/10/18 21:35:08 $; see <a href="#chlog">TODO list and change log</a></small>
</address>
<hr />
<div class="roll"><h2 id="who">Participants</h2>
<p>All <a href="../../#Membership">current members</a> of the
TAG participated in the meeting:</p>
<ol>
<li>Tim <b>Berners-Lee</b> (<i>TBL</i>)<br />
<small>arrived later on Tuesday</small></li>
<li>Dan <b>Connolly</b> (<i>DC</i>)<br />
<small>arrived later on Tuesday</small></li>
<li>Paul <b>Cotton</b> (<i>PC</i>)</li>
<li>Roy <b>Fielding</b> (<i>RF</i>)</li>
<li>Chris <b>Lilley</b> (<i>CL</i>)</li>
<li>Noah <b>Mendelsohn</b> (<i>NM</i>)</li>
<li>Norm <b>Walsh</b> (<i>NDW</i>)</li>
<li>Stuart <b>Williams</b> (<i>SW</i> chair)</li>
</ol>
</div>
<div>
<h2 id="where">Venue, Local Arrangements</h2>
<p>The meeting is at the <a
href="http://www.day.com/content/en/contact/basel.html">Day office in
Barfusserplatz</a>, <a
href="http://www.basel.ch/?lang=en&ctool_page_id=663">Basel</a>.</p>
<blockquote>
Day Software AG<br />
Barfusserplatz 6<br />
4001 Basel<br />
Switzerland<br />
T +41-61-226 98 98<br />
F +41-61-226 98 97<br />
<a href="mailto:ch.info@day.com">ch.info@day.com</a><br />
</blockquote>
<p>The TAG thanks Day Software for a terrific job of hosting our
meeting, and for supporting Roy Fielding's participation in the TAG.
Special thanks to Jean-Michel Pittet for his contributions to the
hosting arrangements.
</p>
</div>
<div>
<h2 id="agenda">Agenda</h2>
<ol>
<li><a href="#administrivia">Administrative</a>
<ol>
<li><a href="#start">Convene, take roll, review agenda</a></li>
<li><a href="#meeting-plans">Future meeting plans</a></li>
<li><a href="#revrec">Review of records</a></li>
<li><a href="#staffcon">TAG staff support</a></li>
<li><a href="#chartpat">TAG Charter, patent policy</a></li>
<li><a href="#tagac">AC report for TAG</a></li>
</ol>
</li>
<li><a href="#webarch-dc">A review of the 28 Sep webarch draft</a></li>
<li><a href="#archgen">Representations over-constrained?</a></li>
<li><a href="#lc-comments">WebArch LC#2 Comments</a></li>
<li><a href="#infores">Information Resources, Web Resources and
httpRange-14 (I)</a></li>
<li><a href="#infores2">Information Resources, Web Resources and
httpRange-14 (II)</a></li>
<li><a href="#lc2qa">Outstanding comments from the Quality Assurance Working Group</a></li>
<li><a href="#lcstatus2">WebArch LC#2 Comments (II)</a></li>
<li><a href="#htxl">xlinkScope-23, comments from HTML WG</a></li>
<li><a href="#extvers">Planning work on extensibility and versioning</a></li>
<li><a href="#HTTPSubstrate-16">HTTPSubstrate-16</a></li>
<li><a href="#infores234">Information Resources, httpRange-14 (Thu)</a></li>
<li><a href="#plan234">Schedule for webarch end-game</a></li>
<li><a href="#txhost">Adjournment, thanks to the host</a></li>
</ol>
<p><em>Other items from the
<a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0184.html">proposed
agenda</a> were not discussed.</em></p>
</div>
<div class="minutes">
<h2 id="minutes">Minutes</h2>
<div>
<h3 id="administrivia">Administrative</h3>
<div class="roll">
<h4 id="start">Convene, take roll, review agenda</h4>
<p>SW convened the meeting Tuesday morning at 9am. See <a href="#who">attendance</a> above.</p>
<p>SW welcomed Noah to his first TAG ftf meeting. <em>later, after
Noah apologized for perhaps disrupting the discussion of httpRange-14,
Norm said "Don't be silly; you've helped us make more progress in one
day than we made in the last six months."</em></p>
<p>The group reviewed the <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0184.html">proposed
agenda</a>, noting that comments on the 2nd (Aug 2004) last call
webarch document motivated discussion of issues httpRange-14 and
xlink23, and that DanC sent <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Oct/0003.html">comments
5Oct</a> that include agenda requests.</p>
</div>
<div>
<h4 id="meeting-plans">Future meeting plans</h4>
<p>We reviewed the following opportunities to meet in face-to-face:</p>
<dl>
<dt>29th-30th November 2004 <strong>Boston, MA, USA</strong></dt>
<dd>already scheduled.
<p>Note announcements to W3C members regarding
<a
href="http://lists.w3.org/Archives/Member/w3c-ac-members/2004JulSep/0010.html">W3C@10</a>
and <a
href="http://lists.w3.org/Archives/Member/w3c-ac-members/2004AprJun/0060">W3C
AC Meeting</a></p>
</dd>
<dt>28th Feb- 4th March 2005 <strong>Boston, MA, USA</strong></dt>
<dd>This is the schedule for the W3C Technical Plenary (per <a
href="http://lists.w3.org/Archives/Member/chairs/2004JulSep/0092.html">13 Sep announcement</a>).</dd>
<dt>10-14th May 2005 <strong>Chiba, Japan</strong></dt>
<dd><a href="http://www.www2005.org/">WWW2005</a></dd>
<dt>6-7 June 2005 <strong>Cannes, France</strong></dt>
<dd>This is the plan for the W3C AC meeting (per <a
href="http://lists.w3.org/Archives/Member/chairs/2004JulSep/0092.html">13
Sep announcement</a>)
</dd>
<dt>Summer 2005 in Kanas City</dt>
<dd>DanC made a tentative offer to host (<a
href="http://lists.w3.org/Archives/Member/tag/2004Sep/0006.html">6 Sep)
</a></dd>
<dt>October 2005?</dt>
</dl>
<p>Regarding the Nov 2004 meeting, NM confirmed plans to attend; SW
offered regrets, noting he could travel Monday (29 Nov) at the
earliest.</p>
<p>Chris noted that the W3C Technical Plenary is a great for meeting
with others but not so good for advancing our own work. There were
some inquiries about the program committee. PC and NDW are likely to
have obligations that week that affect TAG meeting scheduling.</p>
<p>In response to a question from Paul about where the webarch
document would likely be in March 2005, there was discussion of the
division of <a href="../../tag/issues">issues</a> between those we
plan to treat in the 1st edition and those we plan to treat in later
editions, and to what extent the 1st edition not only emphasized the
deployed web but over-constrained the architecture based on it. SW
noted that our 'heartbeat' obligations to publish regularly come due
again in Nov.</p>
<p>PC asked about the timing of the TAG election; SW said the results
should be available by late Jan/early Feb; PC asked about a meeting in
the first week of February 2005 to bring new members up to speed; a
poll showed insufficient support. The importance of letting TAG
candidates know the schedule was re-iterated.</p>
<p><em>Further discussion of future ftf meetings was postponed until
on Weds AM; the meeting continued with <a href="#webarch-dc">a review
of the 28Sep editor's draft</a>.</em></p>
<p><strong class="resolved">RESOLVED: to meet next 18 Oct and cancel
the 11 Oct telcon, <em>TBL</em> abstaining.</strong>. NM at risk due
to plane flight landing 1 hour before TAG telcon.</p>
<p>PaulC asked about the 22 Nov teleconference, a week before Nov f2f,
and US thanksgiving. Stuart, Noah, and Paul reported conflicts.
Stuart offered regrets for 15th and 22nd Nov; NDW offered to chair 15
and 22 Nov.
</p>
<p>We noted that scheduling during the Technical Plenary week depends
on various factors outside our control, but based on the information
at hand, we <strong class="resolved">RESOLVED: to meet 1/2 day on 28
Feb 2005 in Boston, MA, USA, and for TAG members to participate on a
best-effort basis in liaison meetings throughout the week of the W3C
Technical Plenary.</strong> Timbl noted a possible conflict with the
2nd half of that week. Paul suggested that if we have a Proposed Rec
we will be collecting input on the second edition of the Web
Architecture document.</p>
<p>Chris offered to host a meeting co-located with the W3C AC meeting
June 6-7 2005 in Cannes, France. We noted the risk that upcoming
elections and appointments would impact scheduling decisions, but
based on the information at hand, we <strong
class="resolved">RESOLVED: to meet 8-10 June, South of France near
Cannes host Chris/ERCIM</strong>. Dan offered tentative regrets, not
having enough information to commit to anything beyond remote
participation at this time. TimBL was also unable to comfirm
in-person attendance.</p>
<p>Norm offered to host in Western Mass, contingent on his availability
to stand for election and subsequently getting elected.</p>
<p>Dan confirmed his offer to host in Kansas City, "The City of
Fountains"; he noted the relevant airport is MCI, Kansas City
International and gave a brief geography lesson about Kansas City
Kansas, Kansas City Missouri, and Overland Park. Several members
asked about when flights arrive and leave Kansas City; DanC wasn't
familiar with the schedules but Noah noted that a quick search of
American Airlines (for March dates, as Sep 2005 is not posted yet)
suggests that return options from Kansas City to Boston are (Lv: 3:04P
Ar: 8:42P) or (Lv: 5:13P Ar: 10:30P). Noting the various risks as
before, we <strong class="resolved">RESOLVED: to meet 20-22 September,
in Kansas City, DanC to host</strong>
</p>
</div>
<div><h4 id="revrec">Review of records</h4>
<p><strong class="resolved">RESOLVED: to accept <a href=
"http://lists.w3.org/Archives/Public/www-tag/2004Sep/att-0170/minutes.html"
>27 Sep minutes</a>, amended to show regrets from RF.</strong></p>
<p>PaulC reported, with regret, that he had not yet found time to
make substantial progress toward a summary
of the Aug ftf meeting. Chris reported success with David Booth's IRC
post-processing tool (<a
href="http://lists.w3.org/Archives/Public/www-tag/2004Oct/att-0006/tagtest.html">output
from yesterday's IRC log</a>) and offered to help. <strong
class="action">ACTION CL: Chris collect IRC logs from last f2f ( cf <a
href="http://lists.w3.org/Archives/Member/tag/2004Aug/0026.html">pointers
for assembling meeting minutes</a> of 11 Aug) and turn into
minutes.</strong></p>
</div>
<div>
<h4 id="staffcon">TAG staff support</h4>
<p>Stuart noted that Ian Jacobs has taken on the role of head of W3C
Communications, and is consequently not available to participate in
the TAG (cf <a
href="http://lists.w3.org/Archives/Member/tag/2004Sep/0062.html">Role
changes</a>, member only). In discussion of how to recover from the
loss of Ian's contributions, several lauded Norm for his performance
as editor, but we observed that organizing the homepage and issues
list well makes the group much more productive, and lack of staff
support here is costly. DanC said he had done a bit to reduce
expectations about how up-to-date the TAG home page should be: it
shows the regular teleconference schedule but not exceptions.
</p>
<p>TimBL reported success with <a
href="http://www.w3.org/2002/09/wbs/1/">WBS surveys</a> accross a
range of W3C groups and encouraged its use in the TAG. He said he
looks forward to something similarly useful and reusable for action
tracking. RF asked what tools the W3C systems team is comfortable
supporting; DanC said they are comfortable deploying PHP/mySQL tools
and to a lesser extent, XSLT, perl, python, etc. Chris noted Exit, the
system that Ian used and developed, but this is a desktop/client tool,
and not something that distributes the work as RF noted many tools do.
Norm said Exit was difficult to deal with, and that he is often
frustrated by web based forms. DanC noted the LC2 tracking system is
fundamentally email-based, and Noah pointed out that he often works
offline and favors email. <strong class="action">ACTION TBL: to
investigate possible staff contact for TAG, due date 20 October
2004</strong>
</p>
</div>
<div>
<h4 id="chartpat">TAG Charter, patent policy</h4>
<p>Stuart reported that the outcome of recent AB and team discussions
of which role TAG members play for patent policy purposes is that TAG
members are treated as Invited Experts. There was some discussion of
when this outcome takes effect, what opportunities there were for
commenting on the specific text, etc. Paul suggested that the
resulting charter may impact potential candidates' choices about
whether to run. <strong class="action">ACTION SW: get a timescale
from Ian about charter revision and availability</strong>. Paul,
Stuart, and others expressed their appreciation for the responsiveness
of the team to TAG discussion of this topic.
</p>
</div>
<div><h4 id="tagac">AC report for TAG</h4>
<p>Paul volunteered to do the next monthly report and noted that
the AC report is cumulative of the previous three reports.
<strong class="action">ACTION PC: create draft summary for AC, get it
to Steve Bratt by Oct 22</strong></p>
<p>Stuart relayed a <a
href="http://lists.w3.org/Archives/Member/w3c-ac-forum/2004JulSep/0029.html">request
for 'hot topics' for the AC meeting</a>. DanC said that when he
presented to the previous AC on behalf of the TAG, he got little
response to webarch-related questions and suggested that this is to be
expected: the AC is not a technical forum. TimBL concurred; we should
seek organizational input from the AC, not technical. There was little
support for doing a TAG panel at the AC.
</p>
</div>
</div>
<div>
<h3 id="webarch-dc">A review of the 28 Sep webarch draft</h3>
<p><em>based on <a
href="http://www.w3.org/2004/10/05-tagmem-irc#T09-03-19">IRC log
starting Tue 09:03:19Z</a></em></p>
<p>In preparation for the meeting, DanC sent <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Oct/0003.html">comments on the 28Sep editor's draft</a>, some of which were flagged for discussion.</p>
<p>DanC's suggested rewrite of the abstract appealed to the editor and others; suggestions included splitting a long sentence into 3, resulting in something like:</p>
<blockquote>
The World Wide Web uses relatively simple technologies with sufficient
scalability, efficiency and utility that they have resulted in a
remarkable information space of interrelated resources, growing across
languages, cultures, and media. In an effort to preserve these
properties of the information space as the technologies evolve, this
architecture document discusses the core design components of the
Web. They are identification of resources, representation of resource
state, and the protocols that support the interaction between agents
and resources in the space. We relate core design components,
constraints, and good practices to the principles and
properties they support.
</blockquote>
<p>The group discussed proper use of <a href="http://www.ietf.org/rfc/rfc2119">RFC2119</a> keywords, esp</p>
<blockquote>6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmissions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
</blockquote>
<p>After discussion, it seemed that the use of these keywords in
webarch is as appropriate as the use in RFC2119 itself. Concerns about
"conformance" turned out to be misplaced; the constraints in RFC2119
regard interoperability, and as such, the editor was advised to change
the "however" in "in accordance with RFC 2119 [RFC2119]. However,
...".</p>
<p>DanC's request to
add the http/dns example back into section 2.2.1.1. URI ownership and to discuss <tt>data:</tt> as an allocation scheme other than ownership gained some support and the editor is inclined to make that change.</p>
<p>After some discussion of the merits of <q>The distinguishing
characteristic of representation reuse, as opposed to aliasing, is
that the underlying resources are different.</q> from 2.3.2, the
editor dropped it.</p>
<p>DanC expressed disappointment that section 2.5 URI Opacity didn't
make the point about providers rights to choose names, and suggested
adding a link to the siteData-36 issue; NDW said he'd take a look.</p>
<p>There was support for changing <q>Principle: Data-metadata
inconsistency</q> in 3.4 to a constraint, related to 5.3 <q>Principle:
Error recovery</q></p>
<p>Regarding some of the good practice notes, DanC suggested noting QA
in addition to I18N and WAI in the scope section of the introduction;
this appealed to several TAG members and the editor was advised to do
so.</p>
<p>Several concurred with DanC suggested replacement text in 3.3:</p>
<blockquote>a representation consists of a sequence of bytes plus an Internet Media Type [RFC2046] which tells whether the bytes represent text, graphics, video, a spreadsheet, etc. The IANA registry [MEDIATYPEREG] maps media type names to data format specifications (section 4). </blockquote>
<p>NDW expressed willingness to note the security risk DanC raised
regarding "Also, they[binary formats] can be consumed more rapidly by
agents in those cases where they can be loaded into memory and used
with little or no conversion."</p>
<p>DanC congratulated NDW on elaborating on the trade-off regarding
extensibility in section 4.2, but said he would prefer not to include
such a strong good practice note: "A specification SHOULD provide
mechanisms that allow any party to create extensions.". NM concurred,
arguing that there are many, many dimensions to any spec. Most of
these dimensions shouldn't be extensible. Should we allow XML to go
non-Unicode? The trick and the art is to choose just those you want to
worry about. PC expressed a concern regarding synchronization between
the extensiblity/versioning finding and this section of
webarch. <em>Discussion was inconclusive at this point; it continued
in <a href="lc2qa">discussion of QA comments</a>.</em></p>
<p><em>TimBL joined at about 10:33:38Z</em></p>
<p>Regarding the "Good practice: QNames Indistinguishable from URIs"
note in 4.5.5, i.e. "A specification in which QNames represent
URI/local-name pairs SHOULD NOT allow both QNames and URIs in
attribute values or element content, where they would be
indistinguishable."DanC suggested rephrasing as a constraint, perhaps
replacing "SHOULD NOT" with "do not". This was generally
supported.</p>
</div>
<div><h3 id="archgen">Representations over-constrained?</h3>
<p>NM raised a related concern that current web arch is too strong in
implying that all representations are single streams, are specifically
octet streams, and need to be typed with IANA media
types. Generalizing appealled to several group members, but there was
some concern about the impact of such a change at this point in the
process; for example, whether we would owe the community another last
call. <strong class="action">ACTION NM: to take a run through to see how
generalizing 'representation' to be less constrained would look with
more careful terminology, report on whether this looks feasible or
not.</strong> <em>later in the meeting, NM agreed to try to do this in
preparation for the 18Oct telcon</em></p>
</div>
<p><em>Then we had lunch.</em></p>
<div>
<h3 id="lc-comments">WebArch LC#2 Comments</h3>
<p><em>based on <a
href="http://www.w3.org/2004/10/05-tagmem-irc#T12-23-05">IRC logs
starting 12:23:05Z</a></em></p>
<p>We started reviewing the pending <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/">comments</a>,
viewed thru the <a
href="http://www.w3.org/2001/tag/2004lc/lc-status-report.html">status
report</a> Revision 1.10 of 2004/10/05 12:21:52.</p>
<ol>
<li><b>Request for Review of TAG AWWW 2nd LC Draft.</b>
ACTION SW: to review <a href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0131.html">comments from PatH</a> for issues that merit discussion. <em>DONE later in the meeting</em></li>
<li><b><a href="http://www.w3.org/mid/623505000.20040829013738@bumerang.ro">Comments on Working Draft 5 July 2004</a> - URI Overloading</b> is actually spam (based on a comment on an earlier draft)</li>
<li><b><a href="http://www.w3.org/mid/1E4A0AC134884349A21955574A90A7A50A1C84@trebe051.ntc.nokia.com">"information resource"</a></b> was postponed until <a href="#infores">discussion of comments regarding httpRange-14</a></li>
<li><b><a href="http://www.w3.org/mid/4137E592.8070007@cisra.canon.com.au">non-authoritative syntaxes for fragment identifiers</a></b> RF reported on discussion with the commentor which suggest that removing the "One may compare ..." sentence and the one before it would satisfy the commentor. NDW said that as a result of the discussion he is inclined to remove the sentences and make the point in the section on URI opacity.</li>
<li>postponed till <a href="#infores">discussion of comments regarding httpRange-14</a></li>
<li><b>AWWW, 20040816 release, sections 1 and 2</b> <strong class="action">ACTION NDW: to note
this thread [closed] in the archive per msg from gk.</strong></li>
<li><b>resources/representations [was: random comments on 2nd LC of WebArch]</b> postponed till <a href="#infores">discussion of comments regarding httpRange-14</a></li>
<li><b>too positive on extensibility [was: random comments on 2nd LC
of WebArch]</b> NDW suggested recent edits to 4.x are responsive to
this comment. <strong class="action">ACTION CL: to respond to the commenter for issue
8 pointing to the new draft on extensibility</strong> <em>CL sent <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0001.html">such
a message</a> during the meeting, but it seems worthwhile to leave
this action on the agenda for another meeting to check for a response
from the commentor.</em></li>
<li><b>section 2.2 - what does it mean to 'take on meaning'</b> DC
attempted to satisfy the commentor without changes to webarch, but no
reply has come; DanC suggests that it's reasonable to take silence as
assent in this case, accepting a risk that the commentor will object
at some later point.</li>
<li><b><a
href="http://www.w3.org/mid/0I43008JYYDMD0@mailsj-v1.corp.adobe.com">Use
of "assign" for URI -> resource</a></b> <p>RF found the suggestion to excise "URI owner" helpful, but several others preferred the current text that
explains that 'URI ownership' regards the relationship between URIs
and resources; we <strong class="resolved">RESOLVED: to keep " Constraint: URIs
Identify a Single Resource Assign distinct URIs to distinct
resources." despite the new information from LMM's
comment. <em>RF</em> abstained.</strong>
<strong class="action">ACTION SW: to tell the commenter.</strong>
<strong class="action">ACTION NDW: to fix cross references to "uri allocation" that read "uri assignment"</strong>
</p>
<p>After discussion of other parts of LMM's message, we <strong
class="resolved">RESOLVED: that the TAG uses the term URI ownership
rather than resource ownership because some URIs identify resources
that the URI owner (a.k.a., minter) does not own. For example, when a
URI identifies a physical object that is merely named by the URI
owner.</strong> <strong class="action">ACTION SW: to make this
response to Larry</strong></p>
</li>
</ol>
</div>
<p><em>Then we took a break; remaining comments were discussed later:
<a href="#lc2qa">QA comments</a>, <a href="#lcstatus2">others</a>.</em></p>
<div>
<h3 id="infores">Information Resources, Web Resources and httpRange-14</h3>
<p>A number of comments on the 2nd (16 Aug) LC webarch draft motivated
further discussion of issue <a
href="http://www.w3.org/2001/tag/ilist#httpRange-14">httpRange-14</a>:</p>
<ul>
<li><a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0000.html">Patrick
Stricker's comment</a> and resulting <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/thread.html#0">thread</a>
on "information resource".</li>
<li><a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0057.html">Sandro
Hawke's proposed alternate text</a> and <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/thread.html#59">www-tag
thread</a>.</li>
<li><a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0086.html">Stuart's
web resource proposal</a> (and <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0151.html">revised</a>)
and <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/thread.html#132">www-tag
thread</a>.</li>
<li>For background: <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0111.html">Harry
Halpin/Henry Thompson on "Web Proper Names"</a>.
<p>Also, discussion of same on <a
href="http://lists.w3.org/Archives/Public/www-rdf-interest/2004Sep/thread.html#120">www-rdf-interest@w3.org</a>.</p>
</li>
</ul>
<p>Each participant was invited to give some remarks on the issue:</p>
<ul>
<li>DanC said while he still finds the LC text acceptable, the fact
that it doesn't distinguish between the position that some dogs are
information resources (expressed by Stickler, among others) and the
position that no dogs are information resources (expressed by TimBL,
among others) shows that it's not very useful.</li>
<li>RF said that what we have currently is sufficiently vague that it
doesn't have anything architecturally meaningful to say. Stickler's
comment was: if that's what you want to say then why not call it a web
resource. RF noted that Sandro agreed that what was in the webarch [as
of the 16Aug LC draft] did not actually define information resource as
intended, and thus his proposal was to add meat to that definition and
that his proposal was discussed on the mailing lists with very little
support from others in evidence. RF expressed a preference for
Stickler's proposal.
</li>
<li>NM said that it's not clear that the distinction is crisp enough
to be of benefit to readers, but that he didn't have a well-informed
opinion about what answer is right.</li>
<li>SW said that the 'information resource' distinction was introduced
in response to some comments [on the Dec 2003 LC draft] and seems to
have helped. WS noted a possibly related bit from a conversation
with Larry about ownership: there's need for implicit or explicit
indirection between URIs that are web-page like and URIs that are
real-world or conceptual artifacts; with respect to httpRange-14, one
direction is to use the hash for indirection; the Dublin Core folks
seem to use http redirection, which seems interesting.
<p>SW said that in making the web resource proposal, he got Stickler
to agree that there's nothing in the document that he takes exception
to; his concern is that people will read an implicit resolution into
the httpRange-14 issue in the use of "information resource"; if we're
going to resolve it, we should do so more explicitly.</p>
</li>
<li>Chris said his position was expressed in a <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0137.html">message
</a>
in the thread where Stuart proposed and Jacek seconded to change info
resource to web resource:
<blockquote>
It can be
determined whether a given resource is a Web Resource or not. It exposes
an electronic protocol (such as, for example, HTTP) and it can be
interacted with. It need not return a representation (it might refuse
to, or it might say there are no acceptable representations, etc) but
again, this is all testable technical specification.
It was not possible to determine whether a resource was an information
resource. By the very fact of someone referring to it, all resources
have at least one bit of information (the 'alleged to exist' bit).
</blockquote>
<p><em>in IRC, CL noted an <a
href="http://www.strangehorizons.com/2004/20040405/badger.shtml">example
of confusion re web resources and not web resources</a> ;-)</em></p>
</li>
<li>PC concurred with CL because it answers the question of what is on
the web: is it my intention that makes it so, or is it that it's up a
lot, or does it come and go with the server? He went on to note with
regret that the we're likely to have outstanding dissent regardless of
what we decide, and that this issue is the biggest risk in any plans
to get webarch to REC in 2004.</li>
<li>NDW expressed support for the web resource proposal and
willingness to incorporate it into the webarch draft. He went on to
say that we say you should give URIs to important resources; people
have given them to dogs, and that he has yet to see a useful
distinction between web resources and other resources, though it was
not something he feels strongly about.</li>
<li>TBL said that this is an issue he feels strongly about, though he
has sometimes been a minority of one on the TAG. He explained:
<p>The recent webarch drafts don't make the philosophical distinction
about whether the URI refers to the dog or a picture of the dog; these
drafts have been supported by a community of people who have
experience with the widely deployed web technology where the
distinction is rarely evident, so they don't see the pain. But we're
building the SemWeb architecture on top of the Web architecture, and
in the semantic web, confusing the dog with the picture of the dog is
a serious error. Then we have people like Dublin Core using a URI
without a hash to identify the concept of a title of a book; they
haven't worried about the fact that it's a kind of URI that they would
also use for a web page; since they haven't recursively applied
semantic web technology rigorously to web pages, they don't see the
pain either.</p>
<p>He said he sees only one consistent architecture that isn't in
several layers: the thing up to the hash is a document and the stuff
after the hash gives you a global identifier for something that the
document talks about. This conflicts with existing practice in Dublin
Core, FOAF, and other grass roots ontologies; to pursue this
architecture would be to ask them to stop and please put in a
hash. There are a lot of FOAF documents out there and it would be
painful to put in a hash, but there are a lot more web pages out there
and this seems to be the price of a consistent architecture.</p>
</li>
</ul>
<p>When asked to demonstrate the inconsistency, TimBL said the <a
href="http://www.w3.org/2004/ontaria/">Ontaria</a> service/project is
making progress toward making the issues clear.</p>
<p>RF observed ambiguity in, for example, the first example in the RDF
Primer, which provides a URI for a "web page" and whether, in the case
of a page including images, that actually refers to the collection of
resources that are combined to make the page or to the HTTP interface
to that web server for only the initial request, or something else? He
suggested that the existing architecture has a variety of
interpretations for a URI: when using a URI to make a request, that
only refers to the initial response that you get back; in other cases
it's identifying the HTML page. He suggested the use of additional
assertions should be used in case it's necessary to determine which is
meant. TimBL said that there's a particular identification
relationship in web architecture, and it's not the relationship
between a URI and an HTML representation, but rather between a URI and
the resource which the HTML document represents.</p>
<p>In the case of a web page consisting of HTML and images, TimBL said
the images are part of the web page resource; that the image tag is
just a shorthand for having the pixels in the HTML file. RF noted that
the HTTP specification doesn't say these things are part of the
relevant resource. NM noted that if we take the URI to refer to the
composed page, that raises questions about what it would mean to
delete it or manipulate it. RF suggested the URI refers to the
application steady state that you get after you interpret the
representation. TimBL suggested the resource is an information bearing
object, and that webarch must say what information it contains: the
image is part of the resource and the message conveyed does include
the picture.</p>
<p>CL gave an example of URI that, when dereferenced, returns a
frameset that contains a single HTML page and pointed out that from a
web architecture perspective, the single page and the framed page are
different; though people will use the URI in the same way, to use the
URI for the HTML page and for the collection of things is a URI
collision. TBL responded that no, none of the URIs in the example
refers to the bits of the representation. <em>It's not clear that
TimBL understood Chris at this point.</em></p>
<p><em>TBL began to relate this to issues with XInclude, which seems
to fit into the architecture at a lower level, but line of discussion
turned out to be not particularly relevant.</em></p>
<p>RF explored the question of the last modified date of such compound
documents, suggesting that using the steady state model avoids
problems with considering all the images, stylesheets etc. in the
answer. NM suggested that in the case of a composed page, a URI for
each of the components is evident, but the composition is a separate
resource which may or may not be clearly named.</p>
<p>RF claimed that ambiguity about what a URI refers to doesn't break
the Semantic Web. TBL stipulated that the core logic of the Semantic
Web is agnostic to many of these issues, but gave an example of one
party using a URI (without a hash) to refer to something that has such
a birthday, and someone else says it has a copyright, and someone else
says that things that have birthdays don't have copyrights; this is
the sort of conflict that webarch should take a side on.</p>
<p><em>Discussion continued, including topics such as ambiguity,
genericity etc.</em></p>
<p>DanC suggested <a
href="http://esw.w3.org/topic/HashSlashDuality">HashSlashDuality</a>,
whose opening statement is "In both sides of the HashVsSlash debate,
the choice of GoodURIs either obscures a document section or an RDF
Property." <em>Discussion of whether to use this in the webarch
document or perhaps a finding was inconclusive at this point, but
continued later.</em></p>
<p>The group considered the <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0057.html">definition
of information resource offered by Sandro</a> briefly.</p>
</div>
<p><em>At this point, we recessed for the evening. Discussion on this
issue continued Weds AM after <a href="#tagac">AC report for
TAG</a>.</em></p>
<div>
<h3 id="infores2">Information Resources, Web Resources and
httpRange-14 (II)</h3>
<p>DanC led a discussion around a list of proposals, asking which one
proposal each person preferred and which proposals, if any, each
person would object to:</p>
<ol>
<li><a href="http://www.w3.org/2001/tag/2004/webarch-20040816/#information-resource">current (28Sep) section 3.1</a></li>
<li>
<a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0086.html">Stuart's
'web resource' proposal</a>
</li>
<li>
<a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0057.html">Sandro
Hawke's elaborated definition of information resource</a>
</li>
<li>
<a
href="http://esw.w3.org/topic/HashSlashDuality">HashSlashDuality</a>
</li>
</ol>
<p>When asked if the proposals should be judged
on whether they resolve the whole of HTTPRange-14, DanC said no, the
target was addressing the outstanding last call comments, though
closing the whole issue would be nice.</p>
<p>RF clarified that the objectionable part of Sandro's proposal was after the 1st paragraph; the part that says 1 is not an information resource, etc.</p>
<p>NM expressed a concern that to use the term 'web resource' for the
set constrained to have representations or be network-accessible or
anything like that overly constrains Web Architecture.</p>
<p>A fifth option emerged from the
discussion: s/information resource/resource/ and remove section 3.1 (ish).
Stuart suggested that RF's 5th option is responsive to comments
from Hayes, e.g. "does anything apply to non Information resources?"</p>
<p>TBL suggests that what he means by 'information resource' is a
concept that predates the Web and is not necessarily connected to
availability on the Web. Norm and Chris observed that
the concept did not seem sufficiently well-defined, testable, nor operational.
TBL suggested that there's something fundamentally different
between a table and a textual work such as the bible.
NM suggested that Claude Shannon's work on information theory
might provide a suitable definition; TBL agreed that yes, that's
the sense in which he's using 'information'. Chris found:</p>
<blockquote>
Claud Shannon's mathematical theory of information was a major breakthrough
in communication engineering: it allows system designers to estimate the
capacity of communication channels and the requirements of information sources,
and also has some application in data storage (since storing away information
and getting it back is rather similar to sending and receiving information)
and possibly psychology. Relation with other subjects has also been suggested
though so far not much important impact has occurred.
<address>
<a href="http://www.comp.nus.edu.sg/~yuenck/ccst01/notes17">notes on Shannon's work</a>
</address>
</blockquote>
<p>CL suggested that this supports RF's argument that surrounding
context should be used to disambiguate what URIs identify, since
surrounding context serves to provide redundancy. NM clarified that he
wasn't referring to lossy channels or redundancy when he suggested
that information theory could help us; he was pretty sure that Shannon
gives a definition of something like "pure information" that is
essentially what you are <em>trying</em> to communicate through the
channel. He said that by analogy, we need not have redundancy in a
temperature value or the words in a poem to say that they are
"information"; we may need redundancy to communicate them with some
predictable probability of success through a noisy channel; HTTP needs
redundancy on the wire, but the "information resource" definition as
information does not involve redundancy.
</p>
<p>Dan suggested that a a textual work can be consumed over the web in
a way that a table cannot; if you see a table and a movie in a product
catalog, while you can learn about the table using HTTP, you can never
consume it to the point where you owe the vendor the price in the
catalog, while with information resources, you can consume them to the
point where you owe the price just by observing representations.</p>
<p>RF argued that definitions of information resource that interact
with URI syntax contradict the principle of URI opacity. TBL countered
that URI opacity only says not to make unlicensed inferences, but this
inference is licensed by the HTTP specification. RF did not agree.</p>
<p>The last straw poll of the session showed:</p>
<ol>
<li><blockquote>
The term Information Resource refers to resources that convey information. Any resource that has a representation is an information resource. A representation consists logically of two parts: data (expressed in one or more formats (§4) used separately or in combination) and metadata (such as the Internet media type (§3.3) of the data). ...
<address>
<a href="http://www.w3.org/2001/tag/2004/webarch-20040816/#information-resource">current (28Sep) section 3.1</a>
</address>
</blockquote>
<dl><dt>Pref:</dt><dd>TBL, NM</dd>
<dt>Object:</dt><dd>PC, CL</dd>
</dl>
</li>
<li>
<blockquote>
The term Web Resource is applicable to resources for which web
acesssible representations are available and/or which may be interacted
with through an exchange of representations. Any resource that has a web
accessible representation is an web resource ...
<address>
<a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0086.html">Stuart's
web resource proposal</a>
</address>
</blockquote>
<dl><dt>Pref:</dt>
<dt>Object</dt><dd>TBL, NM</dd>
</dl>
</li>
<li>
<blockquote>
An "Information Resource" is a collection of information
potentially transmittable via a computer network. Digital forms of
creative works (such as documents and images) are Information
Resources, while certain conceptual entities (such as numbers and
RDF properties) are not. This distinction is becoming useful as
people develop ways to use URIs to identify things which are not
Information Resources.
<p>...</p>
<address>
<a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0057.html">Sandro
Hawke's proposed alternate text</a>
</address>
</blockquote>
<dl>
<dt>Pref:</dt>
<dt>Object:</dt><dd> NDW, CL, RF, PC</dd>
</dl>
</li>
<li>
<blockquote>
In both sides of the HashVsSlash debate, the choice of GoodURIs either obscures a document section or an RDF Property. ...
<address>
<a
href="http://esw.w3.org/topic/HashSlashDuality">HashSlashDuality</a>
</address>
</blockquote>
<dl><dt>Pref:</dt><dd>PC, CL, SKW, DC</dd>
<dt>Object:</dt>
</dl>
</li>
<li>s/information resource/resource/ and remove section 3.1 (ish)
<dl>
<dt>Pref:</dt><dd>RF, NDW</dd>
<dt>Object:</dt><dd>TBL</dd>
</dl>
</li>
</ol>
<p>Dan noted that as only option 4 had no objections, W3C process
suggests it should be pursued. At Noah's suggestion, we explored some
variations on the proposals and combinations of them, without
conclusion. The editor was encouraged to prepare something for discussion
later in the meeting.</p>
</div>
<p><em>Then we went to lunch.</em></p>
<div><h3 id="lc2qa">Outstanding comments from the Quality Assurance
Working Group</h3>
<p><em>based on <a
href="http://www.w3.org/2004/10/06-tagmem-irc#T12-05-25">IRC log
starting at 12:05:25Z, TimBL serving as scribe</a></em></p>
<p>SW noted that our <a href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/att-0170/minutes.html#item04">27 Sep discussion with the QA WG</a> about <a
href="http://www.w3.org/mid/1095351501.2955.11.camel@stratustier">their
comments</a> was inconclusive.</p>
<p>Though many supported the elaboration on the trade-offs around
extensibility and versioning in <a
href="http://www.w3.org/2001/tag/2004/webarch-20040928/Overview.html#ext-version">section
4.2 of the 28 Sep webarch draft</a>, there were mixed opinions on
whether the boxed notes communicated good/best practices
effectively. DanC noted a <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0002.html">message
from Dom</a> to the effect that the QA WG was reviewing the 28 Sep
text and would tell us Monday if it satisfies them.</p>
<p>The participants were sympathetic to the QA WG's point that for
some designs, no extensibility is best; PC checked to see if the <a
href="http://www.w3.org/2001/tag/doc/versioning-20031003">draft
finding on extensibility and versioning</a> reflected this and
discovered that it does not. PC asked if the risk that decisions made
here would affect the finding was acceptable; several said yes, they
don't mind if the finding needs to change as a result of decisions
made today. Eventually, we <strong class="resolved">RESOLVED: to add
another para of explanation in section 4.2.3. Extensibility that says
more bluntly that there are trade-offs here should be added, editor
salting to taste, and to leave the good practice note boxes,
<em>SKW</em>, <em>RF</em>, <em>DC</em>, <em>NM</em>
abstaining.</strong> After review of other points made by the QA WG,
we <strong class="resolved">RESOLVED: Make that change "the long term
benefits of a +well-designed+ extensibility mechanism...."</strong>.
NDW said he has already added some and will add more references to the
QA work to address their comments. <strong class="action">ACTION NDW:
add "for more info, see also" link to <a
href="http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/#extensions">a
section of a QA spec</a> to 4.x</strong>. <strong
class="action">ACTION DC: Report back to QA on our disposition of <a
href="http://www.w3.org/mid/1095351501.2955.11.camel@stratustier">their
comments</a>.</strong></p>
<p>PC asked could the QAWG please review the draft finding? NW
acknowledged that David Orchard is doing most of the technical work on
the finding. <strong class="action">ACTION PC: solicit QA WG review
of draft extensibility/versioning finding</strong></p>
</div>
<div><h3 id="lcstatus2">WebArch LC#2 Comments (II)</h3>
<p><em>based on <a href="http://www.w3.org/2004/10/06-tagmem-irc#T13-46-59">IRC notes starting 13:46:59Z by RF et. al.</a></em></p>
<ol start="12">
<li><b><a href="http://www.w3.org/mid/20040920110533.JVAV9978.mta13.adelphia.net@mail.adelphia.net">Cyberspace analogous to set of all sets: URIs & URLs</a></b> DC found few specific suggestions in this comment; he responded, asking if the commentor could be more specific.</li>
<li><b><a
href="http://www.w3.org/mid/1095782045.2943.125.camel@Kalb">Representation
of a secondary resource?</a></b> We reviewed the primary/secondary
terminology in <a
href="http://www.w3.org/2001/tag/2004/webarch-20040928/Overview.html#media-type-fragid">section
3.3.1</a>, and noted a related comment, <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0003.html">Late
last-call comment on AWWW</a> Graham Klyne (Tuesday, 5 October). We
discussed ways to clarify that primary/secondary is a relationship
between resources, not disjoint sets of resources: replacing the
terms, getting rid of them, diagrams (ala <a
href="http://www.w3.org/DesignIssues/Model">a design note</a>),
etc. RF noted the terms are defined in the URI specification. DC
pointed out an error in the second bullet... "One cannot carry out
.."; this is not true because it assumes that secondary resource is a
class. ACTION NDW: draft for section 3.3.1 to clarify
primary/secondary (<em>done in <a href="#lc345">later comment review
session</a></em>).
</li>
<li><b>web faster</b> spam. <strong class="action">ACTION DC: make sure "web faster" doesn't bother the chair next time he's doing an agenda</strong></li>
<li><b>KD002</b> <a href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0126.html">Karl's clarification</a> DC said Karl seems to be asking that we say that all Web standards are just as important as the URI standard; he disagreed, noting that URIs have a distinguished place in Web architecture; he noted a comment from Klyne asking that we state the special role of URIs more strongly, and some recent text to that effect:
<blockquote>To achieve this goal, the Web makes use of a single global identification system: the URI. URIs are a cornerstone of Web architecture, providing identification that is common across the Web.
</blockquote>
<p>NM concurred, noting URIs are the one thing that can't be replaced without fundamentally departing from the Web architecture.
<strong class="action">ACTION DC: point out new "URIs are central to web arch" text in reply to Karl, ask if that satisfies</strong>
</p>
</li>
<li><b>[Tim Bray] Review of webarch-20040816</b> NW reviewed Bray's
comments, noting which he had incorporated and which he had
declined. There was considerable support for Bray's comment
regarding section 4.6; we <strong class="resolved">RESOLVED: to change
4.6 from "Because of their role in defining fragment identifier
semantics, data" to "Data", <em>DC</em> abstaining.</strong> Since
"future directions" appears in the section headings of similar
sections for identification and interaction, we
<strong class="resolved">RESOLVED: change title of 4.6 to "Future Directions for Data Formats"</strong>
</li>
<li><b>KD-001 [was: Comments on Web Arch WD - 2004-07-05]</b> has since been closed; the status report will be updated to show this presently.</li>
<li><b>KD 004 [was: Comments on Web Arch WD - 2004-07-05]</b> Further
<a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0128.html">clarification
from KD</a> prompted discussion of section 2.4 URI Overloading. DC
suggested using an example of an example document vs. a DTD, where the
problem would be evident to software. CL and RF noted the comment
seemed to be asking whether, since every URI identify a single thing,
are web pages that talk about multiple things? CL suggested answering
"no, web pages that talk about multiple things are
fine (but give each thing an anchor so it can be separately
referenced)" which was generally supported.
<strong class="action">ACTION CL: respond to Karl regarding KD004</strong>
</li>
<li><b>Some Phone Links</b> spam.</li>
<li><b>Bookmarks02</b> spam.</li>
</ol>
<p>PC asked if there were more recent comments. DC noted that the
deadline has passed; while TAG members are welcome to request
discussion of late comments, we have less and less obligation to do so
as time goes by. PC noted the status report seems to be missing <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0133.html">the
29 Sep comment from the HTML WG</a>; DC said that looked like a bug
and he'd investigate.</p>
</div>
<div><h3 id="htxl">XLink-23, comments from HTML WG</h3>
<p><em>based on <a
href="http://www.w3.org/2004/10/06-tagmem-irc#T15-13-33">IRC notes
starting 15:13:33Z</a></em></p>
<p>The <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0133.html">the
29 Sep comment from the HTML WG</a> prompted discussion of issue <a
href="http://www.w3.org/2001/tag/issues.html?type=1#xlinkScope-23">xlinkScope-23</a>. The
discussion started with process/social issues; PC and others noted
that the linking task force has made little progress in the last seven
months; TBL noted several cases of one group not re-using the work of
another. CL noted some technical obstacles to reuse, noting that
designing for reuse intentionally is important. We noted that the SVG
WG chose to use XLink, but the SMILE and HTML WG and perhaps MathML
WGs did not. We noted that <a
href="http://www.w3.org/TR/hlink/">hlink</a> has not been updated in
quite some time, nor has it been integrated into XHTML 2.0; the <a
href="http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-hypertext.html#s_hypertextmodule">hypertext
module</a> does not use hlink. After discussion of various textual
changes we <strong class="resolved">RESOLVED: add that XLink is not
the only linking design that has been proposed for XML, nor is it
universally accepted as a good design. to section 4.5.2. Links in
XML</strong> <strong class="action">ACTION SW: ask the HTML WG if the
qualification we made regarding XLink satisfies their
comments.</strong></p>
</div>
<p><em>Then we broke for the day.</em></p>
<div>
<h3 id="extvers">Planning work on extensibility and versioning</h3>
<p><em>based on <a href="http://www.w3.org/2004/10/07-tagmem-irc#T09-01-43">IRC notes starting 09:01:43Z</a></em></p>
<p>PC asked for a plan for work on extensibility and versioning (<a
href="http://www.w3.org/2001/tag/issues.html?type=1#XMLVersioning-41">XMLVersioning-41</a>). DC
said he'd like to see a shorter (5 page?) finding. NDW said that he's
busy in Nov, so a finding in Oct would suit him better; he said that
Dave Orchard is doing the "heavy lifting". NDW also encouraged dialog
with the XML Schema WG. NM said he participates in the XML Schema WG,
so we now have a direct connection; his <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Aug/0010.html">message
of 6aug to www-tag</a> is relevant. <strong class="action">ACTION
NDW: to report workplan and dates for Extensibilty and Versioning
work.</strong></p>
</div>
<div><h3 id="lc345">Responses from Last Call commenters</h3>
<p><em>based on <a
href="http://www.w3.org/2004/10/07-tagmem-irc#T09-08-33">IRC notes
from 09:08:33 to 09:50:59</a></em></p>
<ol start="16">
<li><b>[Tim Bray] Review of webarch-20040816</b> NDW led discussion of
<a
href="http://lists.w3.org/Archives/Member/tag/2004Oct/0019.html">further
input from Bray</a>. NDW is inclined to fix "If rep communicates the
state of the resource inaccurately, this inaccuracy or ambiguity may
lead to URI collision" in 3.2.1. Regarding "exceptional circumstances" NDW is inclined to add a clarifying example.
There was little support for Bray's suggestion to remove XML
Schemas from the list of acceptable representations of namespace
documents.</li>
</ol>
<ol start="13">
<li><b><a href="http://www.w3.org/mid/1095782045.2943.125.camel@Kalb">Representation of a secondary resource?</a></b> After further discussion of how to clarify,
we <strong class="resolved">RESOLVED to clarify ala: "The terms ?primary? and
?secondary? in this context do not limit the nature of the
resource?they are not classes. In this context, primary and secondary
simply indicate that there is a relationship between the resources for
the purposes of one URI: a URI with a fragment identifier. Any
resource can be identified as a secondary resource. It might also be
identified using a URI without a fragment identifier, and a resource
may be identified as a secondary resource via multiple URIs. The
purpose of these terms is to enable discussion of the relationship
between such resources, not to limit the nature of a resource." with
some discretion to the editor regarding pronoun references.
</strong> <strong class="action">ACTION DC: to reply to commenter re primary and secondary resources.</strong>
</li>
</ol>
</div>
<div><h3 id="HTTPSubstrate-16">HTTPSubstrate-16</h3>
<p><em>based on <a
href="http://www.w3.org/2004/10/07-tagmem-irc#T09-51-33">IRC notes
starting 09:51:33Z</a></em></p>
<p>DanC noted an upcoming W3C/IETF liaison meeting 14 Oct. After some
discussion of the history and status of issue <a
href="http://www.w3.org/2001/tag/issues.html?type=1#HTTPSubstrate-16">HTTPSubstrate-16</a>,
<strong class="action">ACTION DC: recruit someone to write a
counterpoint to RFC3205 CONTINUES</strong>.</p>
</div>
<div><h3 id="infores234">Information Resources, httpRange-14 (Thu)</h3>
<p><em>based on <a
href="http://www.w3.org/2004/10/07-tagmem-irc#T07-36-08">IRC notes
starting 07:36:08Z</a>, continuing with <a
href="http://www.w3.org/2004/10/07-tagmem-irc#T12-48-09">notes
starting 12:48:09Z</a></em></p>
<p>NW introduced <a
href="http://www.w3.org/2001/tag/2004/webarch-20040928/Infosrc-rewrite.html#information-resource">a
rewrite of section 3.1. Information Resources and Representations</a>
for discussion. While it addressed CL's objection, RF and DC found it
had insufficient motivation.</p>
<p><em>We then went on to discuss <a href="#extvers">extensibility and
versioning</a>, and came back to this topic after other agenda were
done.</em></p>
<p>In discussion of rationale for the "information resource"
distinction, TBL and CL pointed out that all the material on
representations and much of the material on interactions applies
mostly to information resources and suggested that the term is useful
to contrast "resource", the top/unconstrained class, with the class
that's like documents/files in many discussions. NDW proposed:</p>
<blockquote>
<p>By design a URI identifies one resource. We do not limit the scope of what might be a resource. The term "resource" is used in a general sense for whatever might be identified by a URI. It is conventional on the hypertext web to describe web pages, images, product catalogs, etc. as ?resources?. The distinguishing characteristic of these resources is that all of their essential characteristics can be conveyed in a message. We identify this set as ?information resources?.
</p>
<p>This document is an example of an information resource. It consists of words and punctuation symbols and graphics and other artifacts that can be encoded, with varying degrees of fidelity, into a sequence of bits. There is nothing about the essential information content of this document that cannot in principle be transfered in a representation.</p>
<p>
However, our use of the term resource is intentionally more broad. Other things, such as cars and dogs (and, if you?ve printed this document on physical sheets of paper, the artifact that you are holding in your hand), are resources too. They are not information resources, however, because their essence is not information. Although it is possible to describe a great many things about a car or a dog in a sequence of bits, the sum of those things will invariably
be an approximation of the essential character of the resource.
</p>
<p>
We define the term ?information resource? because we observe that it is useful in discussions of web technology and may be useful in constructing specifications for facilities built for use on the web.</p>
</blockquote>
<p><strong class="resolved">RESOLVED: to replace section 3.1 Information
Resources with an updated to section 2.2 as above, "... We identify
this set as ?information resources?. ..."</strong> <strong
class="action">ACTION SW: to respond to Pat Hayes, Patrick Stickler
and Sandro Hawke giving proposed resolution of Information
Resource</strong>. NDW suggested that the HashSlashDuality text
was no longer worthwhile, and we <strong class="resolved">RESOLVED: to
drop the HashSlashDuality text (section 2.2.1 and descendants in a
draft that was projected) and use as input to finding on HTTPrange-14,
<em>DC</em>, <em>TBL</em> abstaining.</strong> <strong
class="action">ACTION DC: with Norm, develop a finding on httpRange-14
starting with the HashSlashDuality text</strong></p>
</div>
<div><h3 id="plan234">Schedule for webarch end-game</h3>
<p><em>based on <a
href="http://www.w3.org/2004/10/07-tagmem-irc#T14-57-55">IRC notes
starting 14:57:55Z</a></em></p>
<p>After some discussion of publication mechanics, we drafted
the following plan:</p>
<dl><dt>18 Oct</dt>
<dd>NW to provide Editor's Draft<br />
NM to provide branch (NM at risk)<br />
DC to produce PR request (at risk)<br />
</dd>
<dt>
25 Oct</dt>
<dd>
Decide to go to PR</dd>
<dt> 01 Nov</dt>
<dd> Director's Decision telcon
<p>
Would like to be there: CL, SW, TBL</p>
</dd>
<dt> 05 Nov</dt>
<dd> i's dotted, t's crossed<br />
Publication as a PR draft<br />
Call for testimonials
</dd>
<dt> 18 Nov - 06 Dec</dt>
<dd>
Blackout</dd>
<dt>08 Dec</dt>
<dd>
AC Reviews due (05 Nov plus four weeks and a few days)<br />
Testimonials due</dd>
<dt>
13 Dec</dt>
<dd>
i's dotted, t's crossed</dd>
<dt>14 Dec</dt>
<dd>REC published<br />
Press release</dd>
<dt> 25 Dec</dt>
<dd>DC dines on PC's nickle. ;-)</dd>
</dl>
<p><strong class="action">ACTION NDW: to produce an editor's draft by
14 Oct (COB EDT)</strong>. <strong class="action">ACTION DC: draft a
request for proposed recommendation, based on Norm's draft</strong>
<strong class="action">ACTION CL: to cause draft of press release to
happen</strong>
</p>
<p>RF asked what the Nov meeting in Boston would be about, if we
proceed according to this plan; thinking about the next edition of the
Architecture document was the response given by several.</p>
</div>
<div><h3 id="txhost">Adjournment, thanks to the host</h3>
<p><strong class="resolved">RESOLVED: The TAG thanks Day Software for
a terrific job of hosting our meeting, and for supporting Roy
Fielding's participation in the TAG. Special thanks to Jean-Michel
Pittet for his contributions to the <a href="#where">hosting
arrangements</a>.</strong></p>
</div>
</div>
<div><h2 id="chlog">TODO list and Change Log</h2>
<p>In addition to getting this record reviewed by the participants, I
plan to:</p>
<ul>
<li>formally connect LC comments to relevant actions and minutes; integrate into <a href="http://www.w3.org/2001/tag/2004lc/lc-status-report.html">status report</a></li>
<li>formally connect issues to actions (and decisions?); think about how to integrate into
<a
href="http://www.w3.org/2001/tag/ilist">issues list</a>
</li>
</ul>
<p>And I hope to:</p>
<ul>
<li>distinguish "awaiting reply from commentor" from other states in last call comment tracking</li>
<li>note (formally) the lat/long of the meeting place, or at least the nearby airport/train station</li>
<li>photo metadata: foaf:depicts, lat/long</li>
<li>sign the record? include the pgp fingerprints that were exchanged as part of the record?</li>
</ul>
<p>These are the changes v1.12 of 2004/09/30 14:27:15, sent in an <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0184.html">agenda
announcement</a>:</p>
<pre><!-- lot starts on next line -->
$Log: 05-07-tag.html,v $
Revision 1.38 2004/10/18 21:35:08 connolly
minutes are no longer DRAFT
Revision 1.37 2004/10/14 03:13:18 connolly
markup fix
Revision 1.36 2004/10/14 03:12:36 connolly
- NDW's action re 3.3.1 was done during the meeting
- moved "then we broke for lunch" notes outside topic divs
- spell-check
Revision 1.35 2004/10/11 16:59:26 connolly
- input from SW re meeting planning
- typos, missing "RESOLVED", spurious para break
Revision 1.34 2004/10/11 16:30:41 connolly
fix month in title
Revision 1.33 2004/10/11 15:55:42 connolly
added link to GRDDL output
Revision 1.32 2004/10/11 15:52:43 connolly
- summarized last httpRange item, planning item
- summarized httpSubstrate
- summarized adjournment, thanks to the host
- normalized some topic headings, finished agenda section
- added some links where the minutes go out of time order
- folded one of the httpRange sessions into the last one
- moved my TODO items into the changelog section
- finished scribe list
Revision 1.31 2004/10/11 14:48:09 connolly
HTTPsubstrate-16 discussion
Revision 1.30 2004/10/11 14:44:29 connolly
another lc comment session; hmm... merge them together?
Revision 1.29 2004/10/11 14:30:10 connolly
- item: Planning work on extensibility and versioning
Revision 1.28 2004/10/10 18:49:51 connolly
- another infores session
- started on extvers item
Revision 1.27 2004/10/10 13:06:45 connolly
- added grddl profile, transformation link
Revision 1.26 2004/10/10 12:58:13 connolly
summarized xlinkScope-23/HTML WG item
Revision 1.25 2004/10/10 12:37:14 connolly
- finished "Return to the last call status list" agendum
- fixed roll call markup
- fixed abstention markup
- started on xlinkScope-23 discussion
Revision 1.24 2004/10/09 20:36:16 connolly
- summarized item on QA WG lc comments
- normalized some aka's
- tx Jean-Michel
Revision 1.23 2004/10/09 19:27:04 connolly
group photo
Revision 1.22 2004/10/09 13:28:08 connolly
- started working on QA comment session, TBL scribing
- added some pointers from topics to spefic parts of the IRC log
Revision 1.21 2004/10/09 13:05:54 connolly
- summarized the session DanC led on httpRange-14 options
- link attendance info to list on TAG home page
- note xlink23 in agenda
- move some links re W3C@10, AC meeting
- link to WBS from TBL's comments
- figured out which msg CL was using as his opening position on httpRage-14
Revision 1.20 2004/10/09 00:18:21 connolly
connected changelog to agenda announcement
Revision 1.19 2004/10/08 22:57:16 connolly
lots more summarized; started GRDDLing
Revision 1.18 2004/10/08 00:51:35 connolly
- fix heading levels in minutes
- use CSS to clarify nesting of topics in the minutes
- use class markup for decisions/actions, mix with css
- fun with CSS for blockquote
Revision 1.17 2004/10/08 00:19:42 connolly
summarized thru 14:04:17Z break after 1st pass thru LC2 comments
Revision 1.16 2004/10/07 23:36:43 connolly
summarized thru lunch on Tue: DanC's review of webarch
Revision 1.15 2004/10/07 22:00:40 connolly
summarized to 08:44:36Z morning break
revision 1.14
date: 2004/10/07 20:56:47; author: connolly; state: Exp; lines: +43 -24
organizing the meeting page as minutes as well as agenda
revision 1.13
date: 2004/10/05 11:03:07; author: swilliam; state: Exp; lines: +2 -2
*** empty log message ***
revision 1.12
date: 2004/09/30 14:27:15; author: swilliam; state: Exp; lines: +2 -2
*** empty log message ***
</pre>
</div>
</body>
</html>