30-minutes
52.5 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
1488
1489
1490
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang='en'>
<head>
<title>W3C Technical Architecture Group Face to Face Meeting - Wednesday, 30 May 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="W3C Technical Architecture Group Face to Face Meeting - 30 May 2007 (Morning)" name="Title">
<meta content="text/html; charset=iso-8859-1" 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>W3C Technical Architecture Group Face to Face Meeting - 30 May 2007 (Wednesday)</h1>
<h2>30 May 2007</h2>
<p><a href='http://www.w3.org/2001/tag/2007/05/29-agenda.html'>Agenda</a></p>
<p>See also: <a href="http://www.w3.org/2007/05/30-tagmem-irc">IRC log</a></p>
<h2><a name="attendees">Attendees</a></h2>
<div class="intro">
<dl>
<dt>Present</dt>
<dd>Tim Berners-Lee (after 9:30AM), Henry Thompson, Rhys Lewis, Norm Walsh, Dan Connolly, T.V. Raman, Stuart Williams, Noah Mendelsohn.</dd>
<dt>Regrets</dt>
<dd>David Orchard (regrets for Wednesday morning only)</dd>
<dt>Chair</dt>
<dd>Stuart Williams </dd>
<dt>Scribes</dt>
<dd>Noah Mendelsohn, T.V. Raman, and Tim Berners-Lee</dd>
</dl>
</div>
<h2>Contents</h2>
<ul>
<li><a href="#agenda">Topics</a>
<ol>
<li><a href="#item01">Administrivia</a></li>
<li><a href="#item02">Planning Future Meetings</a></li>
<li><a href="#item03">Issue URNsAndRegistries-50</a></li>
<li><a href="#item04">httpRange-14</a></li>
<li><a href="#item05">XML Versioning</a></li>
<li><a href="#item06">Reviewing 'Strategies'</a></li>
</ol>
</li>
<li><a href="#ActionSummary">Summary of Action Items</a></li>
</ul>
<hr>
<div class="meeting">
<p><b>Morning scribe: Noah Mendelsohn</b></p>
<h3 id="item01">Administrivia</h3>
<p class='phone'>
<cite>NW:</cite> I am unlikely to have 90 mins worth of material on namespaceDocument-8.
</p>
<p class='phone'>
<cite>HT:</cite> If we have time during the versioning discussion, I could discuss my progress on a more declarative implementation of the TAG soup tool. This would be a sort of "technology interlude" in the discussion.
</p>
<p class='phone'>
<cite>SW:</cite> Maybe at lunch tomorrow. <br>
... Note regrets for all of Friday for Norm. <br>
... Let's consider minutes of 21 May at <a href="http://www.w3.org/2001/tag/2007/05/21-tagmem-minutes">http://www.w3.org/2001/tag/2007/05/21-tagmem-minutes</a>
</p>
<p class='phone'>
<cite>DC:</cite> Can I edit in the link to Noah's old email after approval?
</p>
<p class='phone'>
<cite>ALL:</cite> Yes.
</p>
<p class='phone'>
<strong class='resolution'>RESOLUTION: The minutes of 21 May 2007 at <a href="http://www.w3.org/2001/tag/2007/05/21-tagmem-minutes">http://www.w3.org/2001/tag/2007/05/21-tagmem-minutes</a> are approved.</strong>
</p>
<h3 id="item02">Planning Future Meetings</h3>
<p class='phone'>
<cite>SW:</cite> I think we've got firm dates for Southampton F2F. You can count on the dates.
</p>
<p class='phone'>
<cite>RL:</cite> Would like to know who is local arrangements coordinator.
</p>
<p class='phone'>
<cite>SW:</cite> I'll check. Any interest in extending a 3rd day, presumably without Tim, and if so is there a facility where we could meet.
</p>
<p class='phone'>
<cite>NW:</cite> I'd like to get a train that afternoon.
</p>
<p class='phone'>
<cite>HT:</cite> I'd like to get home that night.
</p>
<p class='phone'>
<cite>TVR:</cite> It's not clear I'll make the meeting at all, if I come 3 days is OK.
</p>
<a name="action01"></a>
<p class='irc'>
<<cite>scribe</cite>> <strong>ACTION:</strong> Noah to check on Hursley hosting of a 3rd TAG F2F day. [recorded in <a href="http://www.w3.org/2007/05/30-tagmem-irc">http://www.w3.org/2007/05/30-tagmem-irc</a>]
</p>
<p class='phone'>
<cite>SW:</cite> Note tech plenary in Boston week of 5 November.
</p>
<p class='phone'>
<cite>NW:</cite> We need to meet with others there.
</p>
<p class='phone'>
<cite>SW:</cite> I'll send notes to chairs saying we'll be there.
</p>
<p class='phone'>
<cite>HT:</cite> The AC is meeting separately only for 1/2 day, the other day is AC at Tech Plenary.
</p>
<p class='phone'>
<cite>TVR:</cite> We may need to play this by ear. We should hold a room for the TAG for the half day of the AC, and decide based on the agenda when to be in the AC.
</p>
<p class='phone'>
<cite>SW:</cite> Am I hearing a half day meeting on Wed.? I like the idea of bracketing the week, but the Sat. is a problem. How about 1/2 day Monday and Friday?
</p>
<p class='phone'>
<cite>HT:</cite> I'd rather have the TAG meeting on the Thurs.
</p>
<p class='phone'>
<cite>SW:</cite> Tim would probably have to be at AC.
</p>
<p class='phone'>
<cite>HT:</cite> Indeed. Withdraw the suggestion.
</p>
<p class='phone'>
<cite>SW:</cite> I'll go for 1/2 day Monday, 1/2 day Friday.
</p>
<h3 id="item03">Issue URNsAndRegistries-50</h3>
<p class='phone'>
Latest draft of TAG finding: <a href="http://www.w3.org/2001/tag/doc/URNsAndRegistries-50">http://www.w3.org/2001/tag/doc/URNsAndRegistries-50</a>
</p>
<p class='phone'>
Henry is about to present the slides at: <a href="URNsAndRegistries_notes.html">URNsAndRegistries_notes.html</a>
</p>
<p class='phone'>
<cite>SW:</cite> Henry, you said our goal should be to reconcile the two parts of the draft finding.
</p>
<p class='phone'>
<cite>HT:</cite> I tried to step back and take a fresh look at this. <br>
... Let's remember some pertinent quotes from the Web Arch document. <br>
... It strongly urges the creation of URIs, but unfortunately does not say http URIs, which is clearly what it means.
</p>
<p class='phone'>
<cite>Several:</cite> really?
</p>
<p class='phone'>
<cite>HT:</cite> Because, the discussion around it is about retrieving representations.
</p>
<p class='phone'>
<cite>TVR:</cite> Does scheme tie to protocol?
</p>
<p class='phone'>
<cite>NM:</cite> We have an open issue on that.
</p>
<p class='phone'>
<cite>TBL:</cite> That was broken when we created the appearance that the http scheme was tied to the specific HTTP protocol...we're trying to back out of it. The http scheme is fundamentally a namespace; the HTTP protocol is the current technology for looking up resources identified using that scheme.
</p>
<p class='phone'>
<cite>NM:</cite> Would like to explain why the schemeProtocols issue is separate from the one we're discussing now.
</p>
<p class='phone'>
<cite>DC:</cite> Please don't.
</p>
<p class='phone'>
<cite>HT:</cite> From AWWW, "Global naming leads to network effects". The important point is that citations (scribe thinks Henry meant references using URIs, at least in the case of the Web) can successfully resolve from anywhere.
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> (he's at slide 4/9: Connection with "persistent identifiers")
</p>
<p class='phone'>
<cite>HT:</cite> The TAG has a goal not just to protect the Web as it is, but to extend its reach and success <br>
... The slides I'm showing leadto possible answer of "just use the http scheme", BUT, we need to ask, why do people keep hatching new schemes?
</p>
<p class='phone'>
<cite>TVR:</cite> We have 3 puns, http as scheme, as protocol, and as namespace name.
</p>
<p class='phone'>
<cite>HT:</cite> At very least, the namespace thing is not consensus. The TAG position is that you SHOULD put a document at the URI that is the namespace name. <br>
... So, I felt I should change the document to focus on what appear to be the good reasons people don't want to use the http scheme. <br>
... Leads to "there are good reasons you might want to use something other than http, but there are fewer such reasons than you may think" <br>
... What are legitimate concerns? Seem to be three:
</p>
<p class='phone'>
1) Dependence on DNS
</p>
<p class='phone'>
2) Apparent lack of central control
</p>
<p class='phone'>
3) Commitment to serve a representation (especially relevant for info:)
</p>
<p class='phone'>
The real issues seem to be:
</p>
<p class='phone'>
A) Trusting the proprietor
</p>
<p class='phone'>
B) The core motive for positions that sometimes look like "not invented here" (NIH) to us so
</p>
<p class='phone'>
C) Communities want to centralize with well known authority
</p>
<p class='irc'>
<<cite>timbl</cite>> I see this NIH thing as being an artifact of the group/culture/language/boundary sociology in general
</p>
<p class='phone'>
<cite>HT:</cite> So, info: has the appeal that you don't go through IANA to establish it. <br>
... People seem to perceive their chances of reliably hanging onto info: is greater than info.com
</p>
<p class='phone'>
<cite>DC:</cite> misperception
</p>
<p class='phone'>
<cite>TVR:</cite> Some of the value is in just what you see at the head of the string.
</p>
<p class='phone'>
<cite>HT:</cite> I looked into state of first dozen URI schemes and URNs in some specific registries. <br>
... Fair number seem to have been abandonned as not well considered.
</p>
<p class='phone'>
<cite>DC:</cite> Have you saved all that information? Very valuable information.
</p>
<p class='phone'>
<cite>HT:</cite> Yes, planned as appendix.
</p>
<p class='phone'>
<cite>TBL:</cite> Considerations for things like dx.doi.org seem different, since there is an >organization< that takes responsibility for the persistence of the identifer.
</p>
<p class='phone'>
<cite>NM:</cite> Is the problem that you have to renew things like domain names?
</p>
<p class='phone'>
<cite>HT:</cite> Yes, in part.
</p>
<p class='phone'>
<cite>NM:</cite> Subtle, because in practice google is unlikely to forget to renew google.com, IBM is unlikely to forget to renew ibm.com. Still, it's a matter of perception.
</p>
<p class='irc'>
<<cite>Zakim</cite>> timbl, you wanted to point out the possible actial lack of depenecy on the RFC.
</p>
<p class='phone'>
<cite>DC:</cite> And also, even if IBM did lose ibm.com, they have a visible investment, probably trademark, etc.
</p>
<p class='phone'>
<cite>TBL:</cite> I don't think they're that worried about the stability of the RFC registration process. One can imagine something like a legal entity just deciding to hijack a scheme in practice.
</p>
<p class='phone'>
<cite>TVR:</cite> Interesting to look at what people did when there was less process. For a long time, people thought they needed to put www. at head of their Web site DNS name. They got there because they already had, e.g. ftp.example.com
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> I think Tim was saying that the U.S. Library of Congress has authority that's independent of, and perhaps higher than, the authority that the IETF/IANA has in RFC4452.
</p>
<p class='phone'>
<cite>TVR:</cite> Not that psychologically different.
</p>
<p class='phone'>
<cite>HT:</cite> IANA has defined process in place for contesting ownership of domain names, but that cuts both ways. Your DNS name could get taken away.
</p>
<p class='phone'>
(See slides for more on proposed shift in strategy)
</p>
<p class='phone'>
<cite>HT:</cite> The folks promoting info: are not using either http-scheme or URNs because they seem to want to actively discourage dereferencing, in part because they want to capture >legacy< naming schemes. It appears that the use case is one in which dereferencing is perceived as a negative.
</p>
<p class='irc'>
<<cite>timbl</cite>> I was saying that the meaning of info:, like ibm.com, will easily come to have a social weight which exceeds the formal stability of the RFC document or domain name system. If the RFC was changed by the IETF without LoC's agreeemnt, LoC would just continue.
</p>
<p class='irc'>
<<cite>timbl</cite>> Where do we find the list of info: subschemes?
</p>
<p class='phone'>
<cite>HT:</cite> We can debate whether that conclusion about the desirability of dereferencing is a correct one.
</p>
<p class='phone'>
<cite>TBL:</cite> In tabulator we use ISBN numbers, social security numbers, etc. as reverse-functional means of identifying things. <br>
... So, what's the harm of formalizing such things under info:?
</p>
<p class='phone'>
<cite>TVR:</cite> Someone who invents a browser widget that finds things based on Social Security Numbers is effectively building something resembling a URI.
</p>
<p class='phone'>
<cite>TBL:</cite> In this case, the info: scheme seems intended to be non-threatening to those who would be worried if asked to provide lookup service.
</p>
<p class='phone'>
<cite>NW:</cite> I see Dan's point, which is stop pretending they're URIs.
</p>
<p class='phone'>
<cite>HT:</cite> Shows examples of lots of info: registrations, including interesting one for what appears to be an art collection. <br>
... Seems very dereferenceable in principle.
</p>
<p class='phone'>
<cite>NM:</cite> Is there possibly an httpRange14-like confusion? Maybe they misperceive that info: is for the framed pictures in the back room, and if they ever were to put digitized copies on the Web, then >those< would be the ones to get http-scheme URIs.
</p>
<p class='phone'>
<cite>TBL:</cite> I think we should say that some of what's being discussed is doable, but is a different architecture. It's not the Web. There are many, many people out there proposing to reinvent parts of the Web like this. The point is that there's a real cost to doing so.
</p>
<p class='irc'>
<<cite>Norm</cite>> ht_google, it appears that the site is down
</p>
<p class='irc'>
<<cite>Zakim</cite>> DanC_lap, you wanted to talk about economic value and naming
</p>
<p class='phone'>
<cite>TBL:</cite> I'd like to see some work on the persistence of DNS names.
</p>
<p class='phone'>
<cite>HT:</cite> Henry and Dan Brickley have come up with the possibility of a workshop of the stakeholders with interest in long term survival of DNS names. Would the TAG be interested in, in some sense, sponsoring such a thing?
</p>
<p class='phone'>
<cite>TBL:</cite> One possible result would be a new top level name.
</p>
<p class='irc'>
<<cite>Zakim</cite>> Noah, you wanted to ask whether the downside isn't committing to non-dereferencability
</p>
<p class='irc'>
<<cite>ht_google</cite>> <a href="http://info-uri.info/">http://info-uri.info/</a>
</p>
<p class='irc'>
<<cite>Zakim</cite>> DanC_lap, you wanted to concur with a workshop for marketing reason, but to disagrees with details (.org, gandi, ...)
</p>
<p class='phone'>
<cite>NM:</cite> I would like to suggest that the finding include a balanced discussion of 1) to what extent is it a misperception that if you do use the http scheme you'll be under ongoing pressure to deploy something, vs. 2) if you use something else, like info:, you are making a gamble that you will never change your mind about wanting to be integrated with the widely deployed infrastructure of the Web.
</p>
<p class='phone'>
<cite>DC:</cite> I'm not so convinced you want or need a new top-level domain. Some of the existing ones like .org may be appropriate if used right. It all comes down to whether people will pay to get the qualities you want over time.
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> (" The top-level domain, .museum ("dot-museum"), was created by and for the global museum community. It enables museums, museums associations and museum professionals to register .museum Web site and e-mail addresses. This, in turn, makes it easy for users to recognize genuine museum activity on the Internet." -- <a href="http://about.museum/">http://about.museum/</a> )
</p>
<p class='phone'>
<cite>TVR:</cite> Rather than saying "don't invent new URI schemes", we might better say "here's how to know when to invent new schemes", with persistence being one aspect of the discussion.
</p>
<p class='phone'>
<cite>HT:</cite> All the schemes and URN namespaces that were originally behind the creation of this issue, were specifically motivated by persistence.
</p>
<p class='phone'>
<cite>TVR:</cite> It's hard to separate from the other reasons you might want to invent a new URI.
</p>
<p class='phone'>
<cite>DC:</cite> Do you think that's happening here?
</p>
<p class='phone'>
<cite>TVR:</cite> No, probably not in this situation. The risk is that external world would misperceive that we were advising on more than the persistence reason. If it's more complex, then let's deal with the more complex issue.
</p>
<p class='phone'>
<cite>DC:</cite> Doesn't the current draft reference the broader discussion?
</p>
<p class='phone'>
<cite>HT:</cite> Yes, it does mention the other discussion of URI schemes and protocols.
</p>
<p class='irc'>
<<cite>ht_google</cite>> <a href="http://weibel-lines.typepad.com/weibelines/2005/11/for_your_info.html">http://weibel-lines.typepad.com/weibelines/2005/11/for_your_info.html</a>
</p>
<p class='irc'>
"The "info" URI scheme is predicated on the notion that the current Web identifier architecture is incomplete, and will benefit from a commonly recognized mechanism that:
</p>
<ul class='irc'>
<li> acknowledges that sometimes it is useful to decouple identity and resolution</li>
<li> supports a mechanism for bringing legacy identifiers into Web-space without directly maintaining Web server infrastructure</li>
<li> provides for simple registration of identifier namespaces that will benefit from a common registration and declaration mechanism"</li>
</ul>
<p class='phone'>
<cite>DC:</cite> But aren't they running Web sites to track which ones are used and which not?
</p>
<p class='phone'>
<cite>HT:</cite> I doubt that's happening below the top level. Many predate the Web and are closed.
</p>
<p class='phone'>
<cite>SW:</cite> Do you know where you're going next with this?
</p>
<p class='phone'>
<cite>HT:</cite> I am going to try rewriting the first half from the perspective I outlined.
</p>
<p class='phone'>
<cite>SW:</cite> Structure likely to be similar?
</p>
<p class='phone'>
<cite>HT:</cite> Probably not.
</p>
<p class='phone'>
<cite>SW:</cite> What about the lack of alignment between two halves of the document? <br>
... Second half didn't use the setup from the first.
</p>
<p class='phone'>
***MORNING BREAK***
</p>
<h3 id="item04">httpRange-14</h3>
<p class='phone'>
Discussing draft finding "Dereferencing HTTP URIs" at: <a href="http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14">http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14</a>
</p>
<p class='phone'>
<cite>RL:</cite> Proceeds from the assumption that a lot of the confusion traces to people assuming that URIs are mainly for things that feel like Web pages. <br>
... So, I built an example of RDF being used to discussed a unit of measure, which is a much more intangible abstraction. <br>
... That sets up the discussion of representations of things, vs. representations of associated things. Also talk about packaging representations for several things together.
</p>
<p class='phone'>
<cite>TBL:</cite> Don't you use the 303 for each thing?
</p>
<p class='phone'>
<cite>NM:</cite> He's using #; only the URI for the combined resource is going through the wire, with the fragid being applied at the client.
</p>
<p class='phone'>
<cite>TBL:</cite> (on white board) SI#metre
</p>
<div class="photo" style="margin-top:1em; margin-left:.5cm" >
<img style="width:80%" alt="Diagram distinguishing 'si/meter' designates vs. 'si/meter' identifies" src="TAGWedDiagram1.jpg" />
</div>
<p class='phone'>
<cite>RL:</cite> I'm trying to avoid setting up Apache to 303 each one separately.
</p>
<p class='phone'>
<cite>TBL:</cite> Starting with the example, what goes through the wire is just SI. You're giving a 303 on that?
</p>
<p class='phone'>
<cite>RL:</cite> Yes.
</p>
<p class='phone'>
<cite>TBL:</cite> But why? SI is a document with documentation about the various abstractions.
</p>
<p class='phone'>
<cite>HT:</cite> But if it's a document, then why is SI#Metre not a subdocument?
</p>
<p class='phone'>
<cite>RL:</cite> But in mine it isn't a document.
</p>
<p class='phone'>
<cite>HT:</cite> But I'm trying to understand Tim's story.
</p>
<p class='phone'>
<cite>TBL:</cite> Tell the story again. <br>
... .../SI#metre <br>
... Strips to /SI <br>
... Get a 200 on that. <br>
... Gives you a representation.
</p>
<p class='phone'>
<cite>HT:</cite> What media type?
</p>
<p class='phone'>
<cite>TBL:</cite> Say, application/rdf+xml
</p>
<p class='phone'>
<cite>HT:</cite> How do we know about the individual concepts described?
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> (following my nose... got as far as ... <a href="http://www.iana.org/assignments/media-types/application/">http://www.iana.org/assignments/media-types/application/</a> )
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> (got to section 3. Fragment Identifiers of <a href="http://www.ietf.org/rfc/rfc3870.txt">http://www.ietf.org/rfc/rfc3870.txt</a> )
</p>
<p class='phone'>
<cite>HT:</cite> RFC 3870 says, not super clearly, a story about how you can define things that can be referenced with fragids. The thing identified "does not necessarily bear any particular relationship to the thing identified by the URI alone". Refers to RDF concepts document for more information.
</p>
<p class='phone'>
<cite>TVR:</cite> Given that media types play implicitly in all of this, why are they only one level deep with "/", and then the thing with the +?
</p>
<p class='phone'>
<cite>TBL:</cite> The plus is just a convention?
</p>
<p class='phone'>
<cite>DC:</cite> Accident of history. <br>
... Do we agree that the 200 story is OK?
</p>
<p class='phone'>
<cite>All:</cite> yes.
</p>
<p class='phone'>
<cite>HT:</cite> Does the 303 story include....
</p>
<p class='phone'>
<cite>RL:</cite> 303 story is two parts, one for no fragid, the other I found in an example. See email we just got from Leo Sauermann: <a href="http://lists.w3.org/Archives/Public/www-tag/2007May/0056.html">http://lists.w3.org/Archives/Public/www-tag/2007May/0056.html</a>.
</p>
<p class='phone'>
<cite>SW:</cite> I read to the end, but it said nothing about the distinction between URIs with and without fragids.
</p>
<p class='phone'>
<cite>NW:</cite> Whether to discuss here seems open. I don't think we've ever had debate about whether a URI with fragid can reference anything. The question is what the range is of things >without< fragids, so I'm not hugely troubled by lack of fragid discussions.
</p>
<p class='phone'>
<cite>TBL:</cite> There can be performance problems doing a separate 303 for each term. Tabulator got slow when Dublin core went to 303.
</p>
<p class='phone'>
<cite>RL:</cite> I think the rationale for giving a 303 on the base document was in part that.
</p>
<p class='phone'>
<cite>SL:</cite> Can the local cache help you?
</p>
<p class='phone'>
<cite>TBL:</cite> We're talking about the "no #" case, so you don't strip.
</p>
<p class='irc'>
<<cite>RhysL</cite>> the mail points to a link <a href="http://www.dfki.uni-kl.de/~sauermann/2006/11/cooluris/">http://www.dfki.uni-kl.de/~sauermann/2006/11/cooluris/</a>
</p>
<p class='phone'>
<cite>NM:</cite> I think the main point should be about why 200 is inappropriate for a non-information resource.
</p>
<p class='phone'>
<cite>TBL:</cite> Yes, in fact you may be understating it. That is the point here, and should be the main conclusion of the finding: if you get a 200, that means you've got an information resource.
</p>
<p class='phone'>
<cite>TVR:</cite> Can it change over time?
</p>
<p class='phone'>
<cite>TBL:</cite> Yes, but that's not a story we need to tell. There are all kinds of subtleties.
</p>
<p class='phone'>
<cite>DC:</cite> See AWWW, which emphasizes physical resources as being non-info resource.
</p>
<p class='phone'>
<cite>TBL:</cite> Maybe we should add metre to arch doc?
</p>
<p class='phone'>
<cite>DC:</cite> Unconvinced.
</p>
<p class='irc'>
<<cite>Zakim</cite>> DanC_lap, you wanted to note that webarch doesn't say that units, e.g. meter are not information resources. it only clearly says that things with physical mass (people, buildings)
</p>
<p class='phone'>
<cite>NM:</cite> Suggest that when you replace "metre" with something more tangible, you also be sure to make it something where it's really obvious why you'd like it to be the subject of RDF statements. I'm not convinced metre quite passes that test either.
</p>
<p class='phone'>
<cite>TBL:</cite> Discussing <a href="http://www.dfki.uni-kl.de/~sauermann/2006/11/cooluris/">http://www.dfki.uni-kl.de/~sauermann/2006/11/cooluris/</a> <br>
... Risk is confusion, when 200 is returned with HTML, about whether you're getting the document or what the document is about.
</p>
<p class='phone'>
<cite>DC:</cite> Hmm. That's a problem? GRDDL does that. The TAG didn't comment.
</p>
<p class='irc'>
<<cite>ht_google</cite>> <a href="http://www.rfc-editor.org/rfc/rfc2854.txt">http://www.rfc-editor.org/rfc/rfc2854.txt</a>
</p>
<p class='phone'>
<cite>ALL:</cite> Somewhat rambling discussion of whether you can get a 200 on HTML, and have a fragid refer to the concept described by the corresponding piece of the HTML (scribe doubts this quite got the subtlety).
</p>
<p class='phone'>
<cite>HT:</cite> Is it OK for the referent to depend on the media type in the accept header?
</p>
<p class='phone'>
<cite>SW:</cite> What guidance can we give Rhys?
</p>
<p class='phone'>
<cite>RL:</cite> Q. Whould the finding address fragment ids?
</p>
<p class='phone'>
<cite>TBL:</cite> A. Yes.
</p>
<p class='phone'>
<cite>HT:</cite> A. Yes.
</p>
<p class='phone'>
<cite>SW:</cite> Is there a terminology issue, since URI syntax includes fragids?
</p>
<p class='phone'>
<cite>DC:</cite> With respect the question about fragids, my answer was "no".
</p>
<p class='phone'>
<cite>HT:</cite> The email that motivated the issue was only about 303, and not about fragids.
</p>
<p class='phone'>
<cite>TBL:</cite> If you're going to talk about the semantics of 303, we would be doing a service to also talk about 301 and 302. Surely you're doing 200, right?
</p>
<p class='phone'>
<cite>RL:</cite> Yes, I'm doing 200.
</p>
<p class='phone'>
<cite>TBL:</cite> e.g. if I get a 301 or a 303, does it imply what you'll get would necessarily imply you'll get a document? (scribe isn't sure how original statement by Tim parsed...sorry)
</p>
<p class='phone'>
<cite>RL:</cite> Could be chains of 303 indirections.
</p>
<p class='phone'>
<cite>TBL:</cite> I think 303 carries an expectation.
</p>
<p class='phone'>
<cite>RL:</cite> Roy's email doesn't say that.
</p>
<p class='phone'>
<cite>NW:</cite> I'd say if using 303 for this purpose, you should point to a document.
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> coherent options (that perhaps the chair will poll on): A: write a finding whose scope is bounded by the existing decision on httpRange-14 (which says nothing about #-uris) B: write a finding about httpRange-14 _and_ best practices for URIs for units of measure and cars [which involves substantial discussion of fragmentInXML-28 and perhaps the GRDDL case]
</p>
<p class='phone'>
<cite>TBL:</cite> Any <img> tag establishes an expectation that there's an image.
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> (looking at <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4">http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4</a> ... hmm... )
</p>
<p class='phone'>
<cite>NM:</cite> Yes, but crucially, it does not make the referent an image. In the error case, it might not be. You might get another HTML page instead of an image. The story we tell is "The IMG tag was in error, in that it established an expectation that referent R would be an image, when in fact it proves not to be." Crucially, the <img> tag cannot make it be an image.
</p>
<p class='phone'>
<cite>HT:</cite> I've had some concern about the notion that an RDF graph is an information resource, and that there is therefore a question of whether using 200 for application/rdf+xml is appropriate. But, on reflection, I'm now convinced. <br>
... Have we said that?
</p>
<p class='phone'>
<cite>DC:</cite> Yes, in Roy's mail <a href="http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html">http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html</a> <br>
... But we have to make sure the finding captures that. <br>
... si/meter redirects with 303 to si/meter/info
</p>
<p class='phone'>
<cite>TBL:</cite> I conclude from the 303 that si/meter/info should be a document.
</p>
<p class='phone'>
<cite>RL:</cite> What if it isn't?
</p>
<p class='phone'>
<cite>NM:</cite> Tim and I went over that. It's in some sense a claim by the entity doing the 303 that it will be an info resource. If it proves not to be, then the 303 should not have been used.
</p>
<p class='phone'>
<cite>NW:</cite> Not convinced. Have we said that --/love can't redirect with 303 to --/fondness
</p>
<p class='phone'>
<cite>TBL:</cite> I would like that not to be ok.
</p>
<p class='phone'>
<cite>NW:</cite> Why? It's a "see also". I'm saying if you're interested in love, you might also be interested in fondness. Why should fondness therefore be an information resource any more than love was?
</p>
<p class='phone'>
<cite>TBL:</cite> (from earlier) when there's a chain of two 303's connecting three resources, the second 303 is expressing a relationship between the second and third resources, not in general transitively back to the first.
</p>
<p class='phone'>
<cite>NM:</cite> Where do we stand on 303?
</p>
<p class='phone'>
<cite>NW:</cite> Well, I could sign onto a TAG finding that says use it this way.
</p>
<p class='phone'>
<cite>RL:</cite> But 303 means what the HTTP spec says it means.
</p>
<p class='phone'>
<cite>TBL:</cite> We have to explain how this all works.
</p>
<p class='phone'>
<cite>HT:</cite> If I fetch from si/meter with accept of application/rdf+xml, why shouldn't I return the length with code 302?
</p>
<p class='phone'>
<cite>TBL:</cite> That suggests the URI can be used in the future.
</p>
<p class='phone'>
<cite>NW:</cite> 301 - moved permanently, use the new one in the future; 302 - found, temporarily under new URI; 307 - Temporary redirect.
</p>
<p class='phone'>
<cite>HT:</cite> I think 307 says show the user this URI.
</p>
<p class='phone'>
<cite>TBL:</cite> Not sure how 302 and 307 differ.
</p>
<p class='phone'>
<cite>TVR:</cite> What about HTTP vary headers? We talked about that in the generic resource finding.
</p>
<p class='phone'>
<cite>HT:</cite> In that case, they all refer to the same resource, which in that case should be an information resource.
</p>
<p class='phone'>
<cite>TBL:</cite> I want to set down this stuff.
</p>
<p class='phone'>
<cite>HT:</cite> I've come to believe that the New York Times home page, which is very core to popularity of the Web, has many representations.
</p>
<p class='phone'>
<cite>TBL:</cite> Conneg happens on 303's as well as 200s.
</p>
<p class='phone'>
<cite>HT:</cite> I ask for non-info resource about city of Dublin, the 303 might give a different URI according to what the original accept header said. <br>
... APIs wrap some of this.
</p>
<p class='phone'>
<cite>DC:</cite> Yes, in fact W3C has a spec in last call.
</p>
<p class='phone'>
<cite>HT:</cite> But that doesn't constrain, e.g. how Python, does it?
</p>
<p class='phone'>
<cite>DC:</cite> Yes, indirectly, by establishing common practice. <br>
... Think about 3 cases 1) Meter unit of measure 2) city of Dublin 3) GRDDL case (text html with fragid of baseball player) <br>
... How many of these are in scope for this finding?
</p>
<p class='phone'>
<cite>SW:</cite> I would have said first two, not last?
</p>
<p class='phone'>
<cite>NM:</cite> Is the metre case making a different point than Dublin?
</p>
<p class='phone'>
<cite>HT:</cite> Don't think so.
</p>
<p class='phone'>
<cite>SW:</cite> Well, less clear cut whether metre is an info resource.
</p>
<p class='phone'>
<cite>NM:</cite> I think Dublin vs. metre should be orthogonal to whether to cover # or not. Dublin is a better example of a non-info resource than metre either way. <br>
... So, I propose we first decide whether to cover # or just non-#, then use Dublin (or something tangible) for whatever survives.
</p>
<p class='phone'>
Tim is putting a diagram on the board, with status codes down the left, and two columns for each: what the request URI identifies, and what the returned URI identifies.
</p>
<div class="photo" style="margin-top:1em; margin-left:.5cm" >
<img style="width:60%" alt="Implications of HTTP status codes 200, 301, 302 & 303" src="TAGWedDiagram3.jpg" />
</div>
<p class='phone'>
<cite>TBL:</cite> We need to say how the Web works.
</p>
<p class='phone'>
<cite>DC:</cite> Aren't we changing the HTTP spec?
</p>
<p class='phone'>
<cite>TBL:</cite> No we are formalizing it a bit.
</p>
<p class='phone'>
<cite>TVR:</cite> Tim discouraged me from going into the time issue, but I need to.
</p>
<p class='phone'>
<cite>TBL:</cite> I really don't want to talk about time.
</p>
<p class='phone'>
<cite>HT:</cite> The rfc uses SHOULD in refer to obligations for the future.
</p>
<p class='irc'>
<<cite>raman</cite>> Minutes: T. V. Raman
</p>
<p><b>Early afternoon scribe: T.V. Raman</b></p>
<h3 id="item05">XML Versioning</h3>
<p class='irc'>
<<cite>DanC_lap</cite>> Stuart: so looking at the collection... opinions on how to move it forward?
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> DO: I don't hear many "you're missing X" comments lately... have we got a bound on scope?
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> DanC: trying to remember some "you're missinig X" comments... Relax-NG? OWL/RDF?
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> DO: I haven't written about those. but other than that, I'm fairly confident.
</p>
<p class='phone'>
Supposedly scribing here but having a hard time deciding what to write
</p>
<p class='phone'>
Summary of discussion around scoping of XML Versioning document.
</p>
<p class='phone'>
Avoid further feature creep, add explanation where needed, but be aware that adding more explanations might also raise more questions.
</p>
<p class='phone'>
<cite>tvr:</cite> suggestion: reach closure on parts of the finding, rather than waiting fo rthe whole
</p>
<p class='phone'>
<cite>DanC:</cite> is it just about syntax? clearly meaning of an element does come into it.
</p>
<p class='phone'>
<cite>tvr:</cite> version can have 3 interpretations: lang:foo version:bar 3 variants: as specified by lang designer, as generated by producers, and as interpreted by consumers.
</p>
<p class='phone'>
<cite>DaveC:</cite> The definition in the terminology section works, though at present it's a 2 part definition.
</p>
<p class='phone'>
<cite>tvr:</cite> how far down tag soup land do we go with respect to accept set of a language --- as an edge-case: what do we say about self-modifying content?
</p>
<p class='phone'>
<cite>NW:</cite> put cones around that hole and dont fall into it
</p>
<p class='phone'>
discussion around definition of backward compatibility in terminology section.
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> TVR discussed implementations that have 1 codepath to grok v.n+1 that as a matter of course groks v.n, vs having a switch
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> TimBL gives XHTML as an example.
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> (hmm... I'm getting there, but not sure I get it... if I get it, it's orthogonal to the definitions)
</p>
<p class='phone'>
<cite>TimBL:</cite> points out that backward compatibility can be defined based on how one gets there via implementation --- consumers saying L+1 == L +L' vs L+1 must directly consume both L and all parts of L' on a single code path
</p>
<p class='irc'>
<<cite>dorchard</cite>> I think there's a software design question about where the "re-use" is, and which is where and how many "switches" are there.
</p>
<p class='irc'>
<<cite>Noah</cite>> NM: I just noted a few things about the Example 2 diagram, as suggestions...
</p>
<p class='irc'>
<<cite>Noah</cite>> NM: 1) You could more clearly indicate that its the languages, and/or particular texts that are what you're referring to when the diagram says "Forwards compatible"
</p>
<p class='irc'>
<<cite>Noah</cite>> NM: 2) The running text might already say this, not sure, but there is an opportunity to say "by the way, if language N+1 includes all of language N, and with all the same mappings to information, then it follows that we have backwards compatibility"
</p>
<p class='phone'>
<cite>tvr:</cite> another example of graceful degradation getting confused with backward compatibility of languages is the difference between introducing attributes vs new elements in XML based languages. Also, observe that it's not just because of structure playing a role, in the microformats world, attributes carry structure.
</p>
<p class='phone'>
<cite>DO:</cite> Might be an indication that the microformats world will have issues of versioning as it evolves
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> (re "microformats might run into versioning problems", their approach is to just stipulate to that, and manage it sorta centrally, i.e. in "everybody talks to everybody all the time" fashion)
</p>
<p><b>Scribe for remainder of day: Tim Berners-Lee</b></p>
<p class='irc'>
<<cite>timbl</cite>> scribenick: timbl
</p>
<p class='phone'>
[reconvene after break]
</p>
<h3 id="item06">Reviewing 'Strategies'</h3>
<p class='phone'>
Scribe for the following is Tim.
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> DO: ah... good point, Noah... semantics/information
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> ... and connection to terminology
</p>
<p class='phone'>
<cite>NM:</cite> This drops into XML sometimes without much of an explanation.
</p>
<p class='phone'>
<cite>DC:</cite> To what extent is 1.1 'argument by assertion'? Do we present evidence alter? 'It is almost unheard of' etc
</p>
<p class='phone'>
<cite>NM:</cite> I felt the same.
</p>
<p class='phone'>
<cite>DO:</cite> I didn't do a survey .. it is anecdotal.
</p>
<p class='phone'>
<cite>DC:</cite> (Though no actual anecdotes either)
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> (I could live without 1.1 Why Worry About Extensibility and Versioning? )
</p>
<p class='phone'>
<cite>NM:</cite> Many languages just get set and never are revised.
</p>
<p class='phone'>
<cite>NW:</cite> The atom folks say they will never change Atom.
</p>
<p class='phone'>
<cite>NM:</cite> How about 'many languages'?
</p>
<p class='phone'>
<cite>DC:</cite> How about getting rid of section 1.1? Or all except the second-to-last paragraph?
</p>
<p class='phone'>
<cite>NM:</cite> That could become the last para of 1.2.
</p>
<p class='phone'>
<cite>DO:</cite> This section [1.1] gives the motivation for this. The point about keeping languages small is not made anywhere else.
</p>
<p class='phone'>
<cite>NM:</cite> Suppose you keep your existing part 1 and then go into a section on why language change... to me it would be tighter and get to the point. I wouldn't miss [1.1]
</p>
<p class='phone'>
<cite>NW:</cite> I don't object to losing it
</p>
<p class='phone'>
<cite>NM:</cite> 'Component' is defined in part 3 now. This is all discussing XML, but we're still in part 2, which I thought was more general. Have we turned this all into an XML discussion? We need to say generally that languages are texts and can change. Many languages we talk about have some markup substructure. A lot has to deal with how the markup evolves. Maybe in 1.3 we should say that a component is markup.
</p>
<p class='phone'>
<cite>DanC:</cite> There is a reference to the defintions ... but suppose you don't follow them and use a general dictionary. It still works, I think. <br>
... if you were relying on the given definition, I would want it bolded or something. <br>
... Here you could change 'components' to 'parts' even
</p>
<p class='phone'>
<cite>NM:</cite> We could say "here we use XML as an example"?
</p>
<p class='phone'>
<cite>TBL:</cite> I think that the way the components combine in, say, RDF is totally different from for a Markup language. There are several different forms of language.
</p>
<p class='phone'>
<cite>DC:</cite> When I see XML I skip over it and the rest works for RDF here. 'Allowable content may include additions or deletions', for example.
</p>
<p class='phone'>
<cite>HT:</cite> 'Terms' is not defined in the second para, but otherwise his works.
</p>
<p class='phone'>
<cite>NM:</cite> I agree with Tim, and had the concern that section 1.3 doesn't really give much useful guidance for anything other than XML/markup languages. I'd prefer to see it add some insights on those other languages.
</p>
<p class='irc'>
<<cite>timbl_</cite>> I would like to see a hand-off to a future 'versioning RDF-based systems' document
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> HT: 1.3 could perhaps start "One of the most important aspects of a change is whether or not it is backwards or forwards compatible."
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> (after 20 seconds of thought, I prefer it as is.)
</p>
<p class='phone'>
<a href="http://www.w3.org/2001/tag/doc/versioning-strategies-20070518.html">http://www.w3.org/2001/tag/doc/versioning-strategies-20070518.html</a>
</p>
<p class='phone'>
[discussion of the sections 1.1-1.3 seems to settle on a conensus more or less with it as it is]
</p>
<p class='phone'>
adding optional components (e.g. elements and/or attributes, or classes and properties)
</p>
<p class='phone'>
^ suggests
</p>
<p class='phone'>
<cite>NM:</cite> How about adding under "Some typical incompatible changes:" adding "Adding new components which change the semantcis of existing ones". <br>
... ... For example, "If this doesn't work, then none of that happens"
</p>
<p class='phone'>
<cite>TBL:</cite> Many languages non markup-like have a form of compoents, such as RDF graphs which have ontology terms, or C which has a generic syntax but a set of library routines, etc. Not only XML.
</p>
<p class='phone'>
<cite>DC:</cite> 1.4 also defines this in a way.
</p>
<p class='phone'>
<cite>NM:</cite> Any merit to moving 1.4 ahead of 1.3 (and maybe ahead of 1.2) to set up the types of languages, which could lead into definition of component?
</p>
<p class='phone'>
[moving to 1.3.1]
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> DanC: in 1.3.1, is "instances" useful in "The primary motivation to allow instances of a language to be extended" ?
</p>
<p class='phone'>
<cite>NM:</cite> What does "changing instances" mean?
</p>
<p class='phone'>
<cite>SW:</cite> I think it means changing set of possible instances [in 1.3.1]
</p>
<p class='phone'>
<cite>NM:</cite> We are talking about the thought processes of those involved?
</p>
<p class='phone'>
<cite>DO:</cite> Specifically the decentralized process.
</p>
<p class='phone'>
<cite>NM:</cite> Do we need to distinguish instances from texts, or just say texts?
</p>
<p class='phone'>
<cite>DO:</cite> texts.
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> (yes, I'd be happy to never use "instance"; "text" works for me.)
</p>
<p class='phone'>
<cite>NM:</cite> I think 1.4 misses the opportunity to talk about the recursive nature of this when text is nested within markup and markup nested in text, so the whole versioning applies recursively.
</p>
<p class='phone'>
<cite>TBL:</cite> Say 'embed' of elements before 'recursive' of languages.
</p>
<p class='phone'>
<cite>NM:</cite> Suppose I have a story about a document about colours , red, blue, green... [missed] now the finding is writing mainly about documents and markup .. but the attribute value color options are in fact a very important and overlooked part of the language's evolution. If new colors are allowed, or old ones disallowed, that's an important versioning change, but the markup is unaffected.
</p>
<p class='phone'>
<cite>TVR:</cite> When in python, I mention at the top of the document things I will import, then if foo() occurs inside the document without having been imprted is illegal.
</p>
<p class='phone'>
<cite>NM:</cite> Many different ways of composing vocabularies.
</p>
<p class='phone'>
<cite>TVR:</cite> That example is one of structure masquerading as text.
</p>
<p class='phone'>
<cite>NM:</cite> What about the change from an attribute to 'red' or 'green' to 'red', green , or flashing amber?
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> (ok, yes, a sentence or two added to the last para in 1.4 Kinds of Languages could usefully discuss embedding/recursion.)
</p>
<p class='phone'>
<cite>TBL:</cite> I agree that the embedding of languages is very widespread and often overlooked. in fact to check a web page is safe (in email, say) you have to check the embedded script, to see what it doesn. That may contain embedded CSS. RDF XML literals can contain XHTML, and so on. I would like validators to validate recurively, but this involves a lot of cross-reefrence and recursion.
</p>
<p class='phone'>
[We move to section 2.0]
</p>
<p class='phone'>
<cite>Subtopic:</cite> Section 2.0
</p>
<p class='phone'>
<cite>NM:</cite> It seems you have a scale from none to big bang, but you're missing some variants. For example, mechanisms like 'must understand' are interesting in part because they are in-band controls in each text.
</p>
<p class='phone'>
<cite>DO:</cite> If you put in an unexpect version and a must-understand, then you have used a new version of the language.
</p>
<p class='phone'>
<cite>NM:</cite> Not obvious from the text. I would thought that the SOAP language for example would contain all possible headers.
</p>
<p class='phone'>
<cite>DO:</cite> You asked about recursion. The features of SOAP allow headers to be carried.
</p>
<p class='phone'>
<cite>DC:</cite> This is cleared up at 2.2.1, last of the three bullets "SOAP Header Blocks with the mustUnderstand attribute is an example."
</p>
<p class='phone'>
<cite>NM:</cite> I back off my suggested change.
</p>
<p class='phone'>
<cite>DO:</cite> When you add in XML and SOAP and headers, you really have three levels here. XML includes the purchase order language for example.
</p>
<p class='phone'>
<cite>NW:</cite> What to you mean by 'flavors'?
</p>
<p class='phone'>
<cite>DO:</cite> I think the classic is the three namespaces for XHTML: Basic, Strict and Transitional.
</p>
<p class='phone'>
<cite>DC:</cite> I don't think those words convey that .. add more words or delete the bullet.
</p>
<p class='phone'>
[2.0, flavors]
</p>
<p class='phone'>
<cite>DC:</cite> Note changes of style from addressing the audience as 'you' or not. <br>
... More editorial suggestions to come.
</p>
<p class='phone'>
[jump to XSLT2 versioning.]
</p>
<p class='phone'>
<cite>DO:</cite> That is really slick.
</p>
<p class='phone'>
<cite>TBL:</cite> How so ... being able to run xslt2 by an xslt1 processor?
</p>
<p class='phone'>
<cite>Subtopic:</cite> 2.2.4 <br>
... 2.2.2.4
</p>
<p class='phone'>
<cite>subsubsubtopic:</cite> JK
</p>
<p class='phone'>
<cite>DO:</cite> There is not enough treatment of XSLT. It is a case study in how to do versioning.
</p>
<p class='phone'>
<cite>Subtopic:</cite> 2.1
</p>
<p class='phone'>
<cite>NM:</cite> Saying "It's probably obvious that attempting to deploy a system that provides no versioning mechanism is fraught with peril." is fraught with peril. Using or not using an explicit version control architecture is an engineering tradeoff. I think the strategy of just not having any versioning can often work, for large or small systems. <br>
... The versioning can add a lot of complexity.
</p>
<p class='phone'>
<cite>DO:</cite> Should we have an advocacy position?
</p>
<p class='phone'>
<cite>DC:</cite> We currently state but to not support this essential.
</p>
<p class='phone'>
<cite>TBL:</cite> What is included in "versioning mechanism"? 'ignore unknown tags?' 'unknown unknown triples" or verison number on documents?
</p>
<p class='phone'>
<cite>NM:</cite> Reword to mention that it can be very hard for consumers . <br>
... I will skip editorial comments <br>
... "extend existing texts' .. this is extending the defined text set?
</p>
<p class='phone'>
<cite>DO:</cite> yes
</p>
<p class='phone'>
[discussion of the difference]
</p>
<p class='phone'>
<cite>NM:</cite> The idea of a processing model is not the right basis for this discussion. We should talk about compatibility of texts, and the compatibility of information inferred from those texts.
</p>
<p class='phone'>
<cite>TBL:</cite> I agree. Specs should not define processing models, it is better to define the meanng of documents in the language. (generalization)
</p>
<p class='phone'>
<cite>NM:</cite> I think by the way that the defined set and e accept set is less useful than we thought. This is a matter of degre, and I would tell a stotu more like: A language whoch can be deteriend from any texts in its set, where I am not distinguishing two sets.
</p>
<p class='phone'>
Suppose my language is defined to extensive, and is, say, an address language. Assume that version 1 requires some fixed markup such as Street, City, State, etc., but allows arbitrary additional markup immediately following the state. Importantly, assume the specification says that the information from such additional markup is not to be ignored completely, but is to be considered part of the address, formatted in some generic way (perhaps tagname=value) when the address is printed, etc.
</p>
<p class='phone'>
Then in the second version I add countries, allowing country USA. That was originally in the accept set , but I move it into the defined set.
</p>
<p class='phone'>
I can say that for example for a pretty-print application or a shipping label printer, should present or store or print the extension tags.
</p>
<p class='phone'>
I could as inventor of the language write that down.
</p>
<p class='phone'>
In version 2 of the language, I document the 'country' tag.
</p>
<p class='phone'>
but what I get from this 'accept set' and 'defined set' is saying that the first languag ehas a defined set which excludes the country. This suggests that the country is not in the defined sem so dropign the country is mandatory according to DO's document. However, you can print and store stuff which is more or less in the accept set but not the defined set.
</p>
<p class='phone'>
<cite>DC:</cite> In 2.2..1.1, it could be read as "ALL langauge ALWAYS must ".. a misreading.
</p>
<p class='phone'>
<cite>NM:</cite> Beware the 'Must'. they say you must do this in terms of subsitutions. <br>
... I don't think that is a good rule. I think the original language should say what you can get. <br>
... What about 'view source' .. should it ignore ignored tags and not show them?
</p>
<p class='phone'>
<cite>TBL:</cite> Objection .. that is a debugging tool, not the main application.
</p>
<p class='phone'>
<cite>NM:</cite> I would say that the old language has limited semantics for the country tag, and the new one has much richer.
</p>
<p class='phone'>
<cite>TVR:</cite> I think it is interesting to think about the fact that it is consuming a subset of the labnguage. Back-compatability requires that every V4 consumer MUST consume every Version 3 document.
</p>
<p class='irc'>
<<cite>DanC_lap</cite>> (a) I think I see Noah's point that the good practice notes simplify in a way that exclude some designs (b) I think that simplification does more good than harm, but (c) I'm afraid you have to be in this room to know enough to grok it as written
</p>
<p class='phone'>
<cite>NM:</cite> I think the compatablity rule for Forwards compatability should be that, starting with a particulat text, that none of the semantics applied by the newer spec can be inconsistent with that applied by the older spec. <br>
... Lets say that the spec for the old language said, "Everything here must be have to do with the address' then if it is to do with hte address, then the label printer still works. The first spec gets to say that in its own terms.
</p>
<p class='irc'>
<<cite>timbl_</cite>> People do that all the time, stick stuff on labels.
</p>
<p class='phone'>
[meta discussion]
</p>
<p class='irc'>
<<cite>dorchard</cite>> how about namespace-range-versioning?
</p>
</div>
<h2><a name="ActionSummary">Summary of Action Items</a></h2>
<!-- Action Items -->
<strong>[NEW]</strong> <strong>ACTION:</strong> Noah to check on Hursley hosting of a 3rd TAG F2F day. [recorded in <a href="http://www.w3.org/2007/05/30-tagmem-irc">http://www.w3.org/2007/05/30-tagmem-irc</a>] <br />
<br />
[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.128 (<a href="http://dev.w3.org/cvsweb/2002/scribe/">CVS log</a>)<br>
$Date: 2007/06/11 14:35:38 $
</address>
<div class="diagnostics">
</div>
</body>
</html>