31-tagmem-minutes
46.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
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang='en' xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org" />
<title>TAG in Mountain View -- 31 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="TAG in Mountain View" name="Title" />
<meta content="text/html; charset=us-ascii" http-equiv=
"Content-Type" />
</head>
<body>
<p><a href="http://www.w3.org/"><img src=
"http://www.w3.org/Icons/w3c_home" alt="W3C" border="0" height=
"48" width="72" /></a></p>
<h1>- DRAFT -</h1>
<h1>TAG in Mountain View</h1>
<h2>31 May 2007</h2>
<p>See also: <a href="29-agenda">agenda</a>, <a href=
"http://www.w3.org/2007/05/31-tagmem-irc">IRC log</a></p>
<h2><a name="attendees" id="attendees">Attendees</a></h2>
<div class="intro">
<dl>
<dt>Present</dt>
<dd>SW, RL, NDW, DC, TBL, HT, TVR, NM, DO, Ian_Hickson</dd>
<dt>Regrets</dt>
<dt>Chair</dt>
<dd>SW</dd>
<dt>Scribe</dt>
<dd>Henry S. Thompson, Dan Connolly</dd>
</dl>
</div>
<h2>Contents</h2>
<ul>
<li>
<a href="#agenda">Topics</a>
<ol>
<li><a href="#item01">Directions and Priorities</a></li>
<li><a href="#item02">TAG Web presence</a></li>
<li><a href="#item03">Dereferencing HTTP URIs,
resumed</a></li>
<li><a href="#item04">Version Identification</a></li>
<li><a href="#item05">Henry's work on tag soup</a></li>
</ol>
</li>
<li><a href="#ActionSummary">Summary of Action Items</a></li>
</ul>
<hr />
<div class="meeting">
<p class='phone'></p>
<p class='phone'></p>
<h3 id="item01">Directions and Priorities</h3>
<p class='irc'><<cite>ht_google</cite>> Scribe: Henry S.
Thompson</p>
<p class='irc'><<cite>ht_google</cite>> ScribeNick:
ht_google</p>
<p class='phone'>some breakfast noodling on upcoming TAG
priorities...</p>
<p class='phone'>1) Semantic Web Arch</p>
<p class='phone'>2) Web 2.0</p>
<p class='phone'>State; programs; what should have URIs, and
how</p>
<p class='phone'>3) Where can we have an impact</p>
<p class='phone'>4) Injecting more sense of urgency</p>
<p class='phone'><strong class='resolution'>RESOLUTION: Revisit
Monday 1700GMT meeting time after the summer</strong></p>
<p class='irc'><<cite>Noah</cite>> Stuart asked us at
breakfast to noodle on upcoming TAG priorities. I heard two big
themes:</p>
<p class='irc'><<cite>Noah</cite>> From Tim and later
endorsed by Noah: Semantic Web</p>
<p class='irc'><<cite>Noah</cite>> From Henry, Dave and
others: Web 2.0</p>
<p class='irc'><<cite>dorchard</cite>> In think our
priorities should be guided by how much effect we can have.</p>
<p class='irc'><<cite>dorchard</cite>> That's why we have
de-emphasized Web Services</p>
<p class='irc'><<cite>dorchard</cite>> I also think that
Stateful clients are becoming much more prevalent as Rich
Client Apps become more larger and more stateful</p>
<p class='irc'><<cite>dorchard</cite>> This has effects
on REST, use of URIs, and stateful vs stateless apps</p>
<p class='irc'><<cite>raman</cite>> Web Arch is complete
with respect to what was well understood in 2000. Things that
were left unsaid in Web Arch 1.0 have provided room for
innovation --- leading to dynamic Web applications on the data
driven Web. Now that we have seen how the Web has evolved, what
are the next set of architectural principles we can add to Web
Arch to make it more complete with respect to how the Web looks
today? This might be an essential step to</p>
<p class='irc'><<cite>raman</cite>> ensure that the next
phase of evolution progresses from a well-understood,
well-documented base.</p>
<p class='phone'><cite>NW:</cite> Post-WebArch1.0, will the
outline of WebArch2.0 emerge?</p>
<p class='phone'><cite>SW:</cite> Updating WebArch1.0 is a
possible work item<br />
... Version identification and Mime Type respect are possible
areas for revision</p>
<p class='phone'><cite>DC:</cite> Working with our customers
would be good, it would identify more possible gaps<br />
... HTML WG, CDF WG</p>
<p class='phone'><cite>TBL:</cite> SWD/SWEO, ATOM</p>
<p class='irc'><<cite>raman</cite>> backplane work</p>
<p class='phone'><cite>RL:</cite> UWA</p>
<p class='phone'><cite>DC:</cite> More approachable W3C specs.
. .</p>
<p class='phone'><cite>TVR:</cite> Is that our job?</p>
<p class='phone'><cite>RL:</cite> I don't see the Web2.0/SemWeb
divide as very large, there's more in common than there are
differences</p>
<p class='phone'><cite>NM:</cite> Both of these are really just
reality checks on what we do, which is independent/foundational
wrt both of them</p>
<p class='phone'><cite>TVR:</cite> Both W2.0 and SW are natural
evolutions of the original Web, and WebArch should grow to
manifest this</p>
<p class='phone'><cite>SW:</cite> WebArch1.0 tried to focus on
Identification, Representation and Interaction -- do we need a
new one?</p>
<p class='phone'>HST, TVR: No, but much more on Interaction,
which isn't well represented in WebArch1.0</p>
<p class='phone'><cite>NM:</cite> Bill Gates said "The
important standards are the ones on the wire" -- I tend to feel
parallel to that to the effect that the stuff going on between
the user and the browser don't matter very much<br />
... That's wrong, they're important, just perhaps a bit less
than what comes over the wire</p>
<p class='phone'><cite>TBL:</cite> Javascript doesn't change
things, it's components are the functions you can call, so its
an on-the-wire standard just as well</p>
<p class='phone'><cite>NM:</cite> Yes, but when you start
looking at e.g. event percolation up the window hierarchy, I
don't see how that was on the wire</p>
<p class='phone'><cite>SW:</cite> I'm with TBL on this</p>
<p class='phone'><cite>TVR:</cite> It's state that makes things
different<br />
... Repeatability of actions, whether its on-screen, by user,
or not, is what matters</p>
<p class='phone'><cite>NM:</cite> Yes, we need to be careful
about our definition of Interaction -- it's not just
user->machine</p>
<p class='phone'><cite>SW:</cite> What should we focus on at
our next f2f?</p>
<p class='phone'><cite>DO:</cite> Versioning and Web2.0</p>
<p class='phone'><cite>SW:</cite> If we did WebArch 2.0, what
would be in it</p>
<p class='phone'><cite>TBL:</cite> Norm&I should finish our
doc, that would be a start</p>
<p class='phone'><cite>HST:</cite> Add self-describing web and
xml functions</p>
<p class='phone'><cite>SW:</cite> What about our public
face?</p>
<p class='phone'><cite>HST:</cite> I'd like to carry the
summary I did forward, but I don't have the time to commit</p>
<p class='phone'>TBL does whiteboard and DanC projected editing
of possible ToC for WebArch Vol II</p>
<p class='irc'><<cite>DanC_lap</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/webarch2-outline">possible
ToC for WebArch Vol II</a></p>
<p class='phone'><cite>HST:</cite> The Interaction topic
reminds me -- another way in which WebArch is not complete is
that we can no longer treat "User Agent" as a simple cover term
-- the more interaction there is from a page, the less what a
browser presents is available to crawlers, indexes, etc.</p>
<p class='phone'><cite>NM:</cite> That's close to something we
did cover in the Least Power finding</p>
<p class='phone'><cite>TVR:</cite> Not much thought is going
into what is visible and what isn't</p>
<p class='irc'><<cite>Zakim</cite>> DanC_lap, you wanted
to note "unobtrusive javascript" good stuff from WAI/weblog
world and to note that some crawler vendors are looking at
javascript runtimes to combat fraud/spam</p>
<p class='phone'><cite>DC:</cite> The basic principle of
"unobtrusive javascript" (?) is that things should still work
if script is turned off<br />
... Sometimes you're just dead in the water</p>
<p class='irc'><<cite>raman</cite>> <a href=
"http://onlinetools.org/articles/unobtrusivejavascript/">http://onlinetools.org/articles/unobtrusivejavascript/</a></p>
<p class='irc'><<cite>raman</cite>> <a href=
"http://www.google.com/search?e=StructuredResults&q=%22loading+%2E%2E%2E%22&num=25">
http://www.google.com/search?e=StructuredResults&q=%22loading+%2E%2E%2E%22&num=25</a>
says Web Results 1 - 25 of about 336,000,000 for "loading ...".
(0.11 seconds)</p>
<p class='irc'><<cite>Zakim</cite>> DanC_lap, you wanted
to note that some crawler vendors are looking at javascript
runtimes to combat fraud/spam</p>
<p class='phone'><cite>DC:</cite> Crawler adding javascript
engine, to get past innocuous static HTML to the
script-generated e.g. porn spam</p>
<p class='phone'><cite>TVR:</cite> Indexers can't afford to run
huge amounts of script to get at the material to index</p>
<p class='phone'>HT, DO: Encouraged by DC's draft ToC</p>
<p class='phone'><cite>DO:</cite> It won't last, but it's a
good start</p>
<p class='phone'><cite>NM:</cite> Really mean package this in a
separate volume<br />
... goal is to serve the customer, not to recapitulate our
history<br />
... One volume or two is a decision for later</p>
<p class='irc'><<cite>DanC_lap</cite>> <a href=
"http://en.wikipedia.org/wiki/Unobtrusive_JavaScript">Unobtrusive
JavaScript</a></p>
<p class='irc'><<cite>Zakim</cite>> DanC_lap, you wanted
to think out loud about tactics</p>
<p class='phone'><cite>HST:</cite> Similarly, as in WA1, we
don't just dump findings in to a document, we summarise and hit
highlights of findings which are still published elsewhere</p>
<p class='phone'><cite>TBL:</cite> Dependency diagram is a very
useful tool</p>
<p class='phone'><cite>SW:</cite> DC called it a "How-Why"
document?</p>
<p class='phone'><cite>DC:</cite> Each arrow is Why in one
direction and How in the other</p>
<p class='irc'><<cite>DanC_lap</cite>> timbl drew a
how/why diagram on the board. noah takes a photo.</p>
<p class='phone'><cite>DC:</cite> It would be good to have an
editor for this document, so it took on some reality<br />
... E.g. NDW</p>
<p class='phone'>[General approbation]</p>
<p class='phone'><cite>NW:</cite> I'll give it a try</p>
<h3 id="item02">TAG Web presence</h3>
<p class='irc'><<cite>DanC_lap</cite>> [oops; growing
list of things to say]: * group home page (move history) * link
to ht's summaries * issue tracking garbage collect, tools *
education business model * community/trust experiment *
semantic mediawiki</p>
<p class='phone'><cite>HST:</cite> I produced a one para
summary of all the areas of current TAG activity for an online
mag. -- it would be a good thing if that were prominently
linked from the home page and kept up to date</p>
<p class='phone'><cite>DC:</cite> I might try to take that
forward a bit</p>
<p class='phone'><a href=
"http://www.ariadne.ac.uk/issue51/thompson/">http://www.ariadne.ac.uk/issue51/thompson/</a></p>
<p class='irc'><<cite>Norm</cite>> I observe that several
of us have blogs; if we agreed to use a particular tag (no pun
intended), we could aggregate one automatically</p>
<p class='phone'><cite>SW:</cite> I'm very unsatisfied with the
way I have to work to maintain the issues list, editing raw XML
-- I'd like a forms-based interface</p>
<p class='irc'><<cite>DanC_lap</cite>> yes, aggregation
looks cost-effective</p>
<p class='phone'><cite>SW:</cite> There is new support for home
page + issues list maintainance from W3C, maybe we should move
to that</p>
<p class='phone'><cite>TVR:</cite> We should have a blog, to
allow TAG members to write down useful small conclusions</p>
<p class='phone'><cite>DC:</cite> I should take the current
page and reduce its weight, to make it more useful for the TAG
as it tries to do its work<br />
... I'm certainly prepared to look at GCing the issues list and
porting it to Tracker<br />
... Education materials -- W3C is looking at this as a service
which would generate revenue, might look at this<br />
... Would like to try semantic mediawiki some time. . .</p>
<p class='phone'><cite>RL:</cite> +1 to mediawiki</p>
<p class='phone'><cite>DC:</cite> Should we use Technorati tags
for the TAG and aggregate from e.g. NW and DO's blogs?</p>
<p class='phone'>NW, DO: Yes</p>
<p class='irc'><<cite>DanC_lap</cite>> (I don't mean
technorati per say; I mean rel="tag")</p>
<p class='phone'><cite>DO:</cite> Blogging is a real
opportunity, we should be doing our business in a more Web2.0
fashion<br />
... recapture the community's interest in what we're doing</p>
<p class='phone'><cite>RL:</cite> Agree we should upgrade our
tools/web resources -- very hard to find things. I've used and
like Tracker<br />
... Prepared to contribute some time</p>
<p class='phone'><cite>NM:</cite> If we do a blog, we need to
look very carefully at what it's for and how we use it -- is it
for carefully considered and even approved formally, or is it
just for as it were scribbling, more like www-tag</p>
<p class='phone'><cite>SW:</cite> We could use it to address
the 'not much came out of this meeting/telcon' problem?</p>
<p class='phone'><cite>NM:</cite> Would I show stuff to the TAG
first?</p>
<p class='phone'><cite>NW:</cite> No -- just as if your
personal blog<br />
... in principle no different from aggregating wrt TAG tag all
our personal blogs</p>
<p class='phone'><cite>NW:</cite> and of course we don't all
have personal blogs</p>
<p class='phone'><cite>SW:</cite> Musings vs.
pronouncements</p>
<p class='irc'><<cite>DanC_lap</cite>> <a href=
"http://dig.csail.mit.edu/breadcrumbs/node/87">Using RDF and
OWL to model language evolution</a></p>
<p class='irc'><<cite>DanC_lap</cite>> Submitted by
connolly on Wed, 2006-02-15</p>
<p class='irc'><<cite>DanC_lap</cite>> ^ a blog item I
wrote coming out of a TAG ftf</p>
<p class='irc'><<cite>DanC_lap</cite>> <a href=
"http://www.w3.org/QA/2006/10/arch_qa_loop.html">Web
Architecture and Quality: closing the loop October 11,
2006</a></p>
<h3 id="item03">Dereferencing HTTP URIs, resumed</h3>
<p class='irc'><<cite>Stuart</cite>> <a href=
"http://www.ihmc.us/users/phayes/PatHayes.html">http://www.ihmc.us/users/phayes/PatHayes.html</a></p>
<p class='phone'><cite>RL:</cite> I will do some rewrites based
on the input I got<br />
... There were some open topics wrt return codes, clarifying
the http protocol</p>
<p class='phone'><cite>DC:</cite> Are you prepared to edit in
that direction?</p>
<p class='phone'><cite>RL:</cite> Probably, but it depends on
the extent and direction of any additions</p>
<p class='phone'><cite>DC:</cite> I'm attracted by the idea of
looking at something from the customer perspective, what advice
do we give to people who want to name things<br />
... Does the current draft do this?</p>
<p class='phone'><cite>RL:</cite> Yes, but it's not the
headline</p>
<p class='phone'><cite>DC:</cite> I could get behind either
explaining our original decision or giving guidance about
choosing names</p>
<p class='phone'><cite>TBL:</cite> I can only go with 'the
original decision' unless we expand to cover at least 301 and
302</p>
<p class='phone'><cite>SW:</cite> I think the title is wrong --
the HTTP spec tells us how to dereference URIs<br />
... Email thread on www-tag is useful, maybe</p>
<p class='phone'><cite>HST:</cite> I liked the point that a 200
response code _asserts_ that the URI identifies an information
resource, it doesn't _make_ what it identifies _be_ an
information resource</p>
<p class='phone'><cite>DC:</cite> [decision tree for giving
URIs to things]</p>
<p class='phone'><cite>SW:</cite> Back to the email thread --
the snapshot of the state issue is interesting. . .</p>
<p class='phone'><a href=
"http://lists.w3.org/Archives/Public/www-tag/2007May/0058.html">
http://lists.w3.org/Archives/Public/www-tag/2007May/0058.html</a></p>
<p class='phone'>[the URI/URIref distinction brief rathole]</p>
<p class='phone'><cite>DC:</cite> (and TBL) corner cases wrt
information resource: e.g. integer, WSDL interfaces<br />
... Document vs. Information resource</p>
<p class='phone'><cite>TBL:</cite> RDF graph is not a
document</p>
<p class='phone'><cite>NM:</cite> But we can convey the essense
of a graph in a message</p>
<p class='phone'><cite>TBL:</cite> It's the same as the
difference between a document and a parse tree</p>
<p class='phone'><cite>HST:</cite> Back to the units example --
<a href=
"http://www.example.org/.../units">http://www.example.org/.../units</a>
-> application/rdf+xml -- identifies what? An RDF graph?</p>
<p class='phone'><cite>TBL:</cite> no -- identifies the
document == the information conveyed by that RDF graph</p>
<p class='phone'><cite>SW:</cite> Two meanings of 'document' --
got to be careful about that</p>
<p class='phone'><cite>NM:</cite> The last chapter definitely
comes after the first, but that's not true about e.g. rows in a
DB</p>
<p class='phone'><cite>HST:</cite> That's SW's point</p>
<p class='phone'><cite>DC:</cite> So this brings me back to the
question of when you can return 200<br />
... What about individual XML elements, e.g.
"<q>....</q>" ?<br />
... [disagreement among DC, TBL, HST]</p>
<p class='phone'><cite>HST:</cite> In DC's picture, the
'document' in "Document-like" is document-sub-1 -- something
linguistic, in other words<br />
... No, that's wrong, because that appears to descriminate
against e.g. image/jpg or audio/mp3, which we shouldn't do</p>
<p class='phone'><cite>TBL:</cite> So I think it's clear that
classes and properties are not information resources</p>
<p class='phone'><cite>SW:</cite> Norm's document [photo here?]
is an information resource. What the status of the subject of
the RDF description therein is a different question</p>
<p class='phone'><cite>DC:</cite> I don't agree wrt class and
properties -- I have counterexamples in mind<br />
... In summary, when it's clear things are/are not information
resources, name them as you like and return 200/either package
them and use # (and 200) if there are a modest number, or name
them individually and do the 303 thing</p>
<p class='phone'><cite>SW:</cite> I'm not sure about what the
GRDDL case is, but does the same question arise with
client-side application of a stylesheet?</p>
<p class='phone'><cite>NM:</cite> How does this raise a
question?</p>
<p class='phone'><cite>DC:</cite> As HST asked yesterday, the
question is how/why do same-document URIrefs work (e.g.
href="#foo") in stylesheet output</p>
<p class='phone'><cite>NM:</cite> Simple case: HTTP GET, 200,
media type is well-known, fragids identify secondary resources,
all cool<br />
... Harder case -- HTTP GET, 200, media type is xml, there's a
stylesheet, result of ss application seems like a different
media type, so we now have something rather different than the
message</p>
<p class='irc'><<cite>DaveO</cite>> I asked about the
relationship between the "many things" case tying into Web 2.0
with many "embedded" things..</p>
<p class='irc'><<cite>DaveO</cite>> And particularly,
does this guidance apply to Web 2.0 things like Google maps</p>
<p class='phone'><cite>DC:</cite> Not the same as the GRDDL
case, which is, does #jackson refer to the HTML paragraph or
the baseball player</p>
<p class='phone'><cite>NW:</cite> I tend to think of fragids as
identifying something 'in' the document, but of course e.g.
Google Maps could have a very small Javascript document whose
URI was, say, .../map, and the code interprets a fragid to
focus on any point in the world<br />
... The WordNet bug is what we want to avoid, namely,
retrieving all of WordNet in order to deal with
.../wordnet#democracy</p>
<p class='phone'><cite>TBL:</cite> If DC's proposal involves a
title change, I'm opposed to the change</p>
<p class='phone'><cite>SW:</cite> My understanding is that it
does</p>
<p class='phone'><cite>RL:</cite> I wasn't planning to make a
title change yet</p>
<p class='irc'><<cite>Noah</cite>> Note that six photos
of diagrams from the whiteboard are now available on the Web.
Yes, for uninteresting reasons, the first one has an extension
of uppercase JPG and the others have the friendlier jpg</p>
<p class='irc'><<cite>Noah</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/TagThursDiagram1.JPG">http://www.w3.org/2001/tag/2007/05/TagThursDiagram1.JPG</a></p>
<p class='irc'><<cite>Noah</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/TagThursDiagram2.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram2.jpg</a></p>
<p class='irc'><<cite>Noah</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/TagThursDiagram3.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram3.jpg</a></p>
<p class='irc'><<cite>Noah</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/TagThursDiagram1.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram1.jpg</a></p>
<p class='irc'><<cite>Noah</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/TagThursDiagram2.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram2.jpg</a></p>
<p class='irc'><<cite>Noah</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/TagThursDiagram3.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram3.jpg</a></p>
<p class='phone'><cite>RL:</cite> and was not planning to fill
in more wrt 301, 302 etc. yet</p>
<p class='irc'><<cite>Noah</cite>> ARGH, those are
wrong...trying again:</p>
<p class='irc'><<cite>Noah</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/TagWedDiagram1.JPG">http://www.w3.org/2001/tag/2007/05/TagWedDiagram1.JPG</a></p>
<p class='irc'><<cite>Noah</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/TagWedDiagram2.jpg">http://www.w3.org/2001/tag/2007/05/TagWedDiagram2.jpg</a></p>
<p class='irc'><<cite>Noah</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/TagWedDiagram3.jpg">http://www.w3.org/2001/tag/2007/05/TagWedDiagram3.jpg</a></p>
<p class='irc'><<cite>Noah</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/TagThursDiagram1.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram1.jpg</a></p>
<p class='irc'><<cite>Noah</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/TagThursDiagram2.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram2.jpg</a></p>
<p class='irc'><<cite>Noah</cite>> <a href=
"http://www.w3.org/2001/tag/2007/05/TagThursDiagram3.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram3.jpg</a></p>
<p class='phone'><cite>TBL:</cite> I want to cover the space of
response codes (and sequences of them)</p>
<p class='phone'><cite>DC:</cite> Why should this include 301
or 302?</p>
<p class='phone'><cite>TBL:</cite> because I need to know what
cases my code needs to deal with</p>
<p class='irc'><<cite>DanC_lap</cite>> (ht, which of the
.jpg's above is the proposed table?)</p>
<p class='phone'>Table is from yesterday</p>
<p class='phone'>I haven't looked in yesterday's log yet to
findit</p>
<p class='irc'><<cite>DanC_lap</cite>> the table seems to
be <a href=
"http://www.w3.org/2001/tag/2007/05/TagWedDiagram2.jpg">http://www.w3.org/2001/tag/2007/05/TagWedDiagram2.jpg</a>
; the cells are blank.</p>
<p class='irc'><<cite>DanC_lap</cite>> I'm OK for TimBL
to take an action to write it up, and we'll review it.</p>
<p class='irc'><<cite>DanC_lap</cite>> ok I'm OK for rhys
to give it a try</p>
<p class='irc'><<cite>DanC_lap</cite>> Diagram3 has some
stuff.</p>
<p class='irc'><<cite>DanC_lap</cite>> IH: perhaps: good
practice: design a language so that revisions to the language
don't cause problems for user agents</p>
<h3 id="item04">Version Identification</h3>
<p class='irc'><<cite>DanC_lap</cite>> Scribe: Dan
Connolly</p>
<p class='irc'><<cite>DanC_lap</cite>> ScribeNick:
DanC_lap</p>
<p class='phone'>IH stops by</p>
<p class='phone'><cite>IH:</cite> perhaps: good practice:
design a language so that revisions to the language don't cause
problems for user agents</p>
<p class='phone'>taking a look at <a href=
"http://www.w3.org/TR/webarch/#pr-version-info">http://www.w3.org/TR/webarch/#pr-version-info</a></p>
<p class='phone'><cite>DO:</cite> so perhaps the version
information technique should be subordinated under "plan for
extensions, compatibility... "<br />
... this section of /TR/webarch resulted from a snapshot of the
versioning finding from years ago; the versioning finding has
come along way since then; perhaps there's a better snapshot to
take from<br />
... we could update /TR/webarch or publish separately or
whatever</p>
<p class='phone'><cite>NM:</cite> so re version identification,
we're not defending the webarch/#pr-version-info strongly as
written<br />
... right?</p>
<p class='phone'>(many nods)</p>
<p class='phone'><cite>TVR:</cite> if we had a blog...</p>
<p class='phone'><cite>DanC:</cite> we can get one for the cost
of a request...<br />
... to the systems team</p>
<p class='phone'>(NM got some clarification on writing a blog
item after review by the TAG; DanC needs a few more parameters
before requesting a blog get set up)</p>
<p class='phone'><cite>DO:</cite> I'd like us to follow up on
the details of the versioning techniques...
costs/benefits...</p>
<p class='phone'><cite>NM:</cite> do we have an errata
process?</p>
<p class='phone'><a href=
"http://www.w3.org/2001/tag/webarch/errata.html">http://www.w3.org/2001/tag/webarch/errata.html</a></p>
<p class='phone'><cite>DO:</cite> putting it there isn't
enough<br />
... I'd like to put it right in /TR/webarch ... but maybe it's
not worth the cost of a WD</p><a name="action01" id=
"action01"></a>
<p class='irc'><<cite>scribe</cite>>
<strong>ACTION:</strong> NDW to note a problem near
webarch/#pr-version-info in the errata [recorded in <a href=
"http://www.w3.org/2007/05/31-tagmem-irc">http://www.w3.org/2007/05/31-tagmem-irc</a>]</p><a name="action02"
id="action02"></a>
<p class='irc'><<cite>scribe</cite>>
<strong>ACTION:</strong> NM to draft a blog item on
possible semantics of version identifiers for review and, pending creation of a TAG blog
mechanism, post it [recorded in <a href=
"http://www.w3.org/2007/05/31-tagmem-irc">http://www.w3.org/2007/05/31-tagmem-irc</a>]</p>
<p class='phone'><cite>DO:</cite> continuing discussion of
section 2.2.2 Forward Compatible ... I ack concerns around
"processing model" in the Good Practice note</p>
<p class='phone'><cite>NM:</cite> "ignore what you don't
understand" removes the possibility that unknown tags might
appear in the DOM</p>
<p class='irc'><<cite>dorchard</cite>> HTML 2.0 says
markup in the form of a start-tag or end-g, whose generic
identifier is not declared is mapped to nothing during
tokenization.</p>
<p class='phone'><cite>NM:</cite> if you'd written the "ignore
tags you don't understand" part of the HTML spec knowing the
TAG versioning teminology, let's think about how you'd do
it...</p>
<p class='irc'><<cite>dorchard</cite>> HTML 2.0 also says
".. the installed base of HTML user agents supports a superset
of the HTML 2.0 language by reducing it to HTML 2.0:</p>
<p class='phone'><a href=
"http://www.w3.org/MarkUp/html-spec/html-spec_4.html#SEC4.2.1">http://www.w3.org/MarkUp/html-spec/html-spec_4.html#SEC4.2.1</a></p>
<p class='phone'><cite>DO:</cite> the HTML 2 spec follows this
model quite closely... it gives a substitution model...</p>
<p class='phone'><cite>NM:</cite> but this isn't the only way
to do it...</p>
<p class='phone'><cite>DC:</cite> this has happened before...
these good practice notes are being read as applying in all
cases, where it's clear that you (DO) meant them as menu
options</p>
<p class='irc'><<cite>Norm</cite>> Ok.</p>
<p class='phone'><cite>NM:</cite> the semantics you define for
every [lots more words that made the scribe forget these]</p>
<p class='irc'><<cite>dorchard</cite>> IH makes the point
that the "text" case is actually a very small case, it's always
generated by code, no "document" or "text"</p>
<p class='phone'><cite>IH:</cite> question... what's the
audience? spec authors? [yes] what's a text? [sequence of
characters] well, the HTML5 semantics hang on the tree, not on
the texts. we don't always even have a text</p>
<p class='phone'><cite>DanC:</cite> but you have to say what
happens when you start with a text, right?</p>
<p class='phone'><cite>IH:</cite> yes, but that's more of a
corner case</p>
<p class='phone'><cite>DanC:</cite> you've got a harder problem
than the one we're advising on so far</p>
<p class='phone'><cite>NM:</cite> yes, synthetic infosets
matter, etc.</p>
<p class='phone'><cite>IH:</cite> there are some DOMs that
can't be serialized. [SKW: example?] a comment that contains
two dashes in a row. a table inside a p</p>
<p class='phone'><cite>NM:</cite> while the case of no network
connection, totally synthetic DOM is important, we've been
focussed on the large scale case where text comes over the
wire</p>
<p class='phone'><cite>HT:</cite> while using character
sequences vs abstract syntax is somewhat arbitrary, I don't
think much of this would change if we switched to abstract
syntax</p>
<p class='phone'>[missed some]</p>
<p class='phone'><cite>HT:</cite> consider
<banana>...</banana> ... with style...</p>
<p class='phone'><cite>IH:</cite> yes, it's gets styled</p>
<p class='phone'><cite>NM:</cite> that's why I don't like the
substitution model as a "MUST"</p>
<p class='phone'><cite>DO:</cite> ack.</p>
<p class='phone'><cite>TimBL:</cite> [missed]</p>
<p class='irc'><<cite>Zakim</cite>> DanC_lap, you wanted
to suggest that readers are going to need more of a
story/example for 2.2.2... (terminology has the story, but I'd
like that to be inessential)</p>
<p class='phone'><cite>DO:</cite> reasonable suggestion</p>
<p class='irc'><<cite>Zakim</cite>> Rhys, you wanted to
say its not a must ignore, its a substitution rule</p>
<p class='phone'><cite>DanC:</cite> hmm... not clear...</p>
<p class='irc'><<cite>Zakim</cite>> dorchard, you wanted
to propose some rewording during a break</p>
<p class='phone'><cite>DO:</cite> concerning 5 Identifying and
Extending Languages... stipulate "A fundamental ... determine
the language" needs work...<br />
... perhaps I should move some of [this material in section 5]
up?<br />
... I could try a edit in a break</p>
<p class='phone'><cite>DanC:</cite> sounds good; how about
skipping to section 3 for the remaing few minutes before the
break</p>
<p class='phone'><cite>DO:</cite> stipulate in 3.3
"substitution... required..." needs work.</p>
<p class='phone'><cite>SKW:</cite> I wonder if these are
requirements...</p>
<p class='phone'><cite>HT:</cite> "Candidate"
requirement...</p>
<p class='phone'><cite>DO:</cite> makes sense... s/Can ...?/ to
/.../<br />
... [summarizing the draft] it continues with a dozen or so
requirement questions, then raises design questions, then
surveys several languages showing how they answered the design
questions.</p>
<p class='phone'><cite>DanC:</cite> consider moving one of them
up</p>
<p class='phone'><cite>DO:</cite> or carrying one of them...
maybe HTML... thru</p>
<p class='phone'>[BREAK]</p>
<p class='irc'><<cite>Norm</cite>> scribenick: Norm</p>
<p class='phone'>Reconvene</p>
<p class='phone'><cite>DO:</cite> I did a quick rewrite of
2.2.2, Forwards Compatible</p>
<p class='irc'><<cite>Zakim</cite>> DanC_lap, you wanted
to note that <img> is a pretty bad example of forward
compatibility</p>
<p class='phone'><cite>DC:</cite> The alternate text should
have been content, not in an attribute</p>
<p class='phone'><cite>DO:</cite> I like it because it's not
tokenized if the img isn't recognized</p>
<p class='phone'><cite>DC:</cite> Users don't like to have
images ignored, they want to see the alt text.</p>
<p class='phone'><cite>DO:</cite> I'm talking about HTML
2.0.</p>
<p class='phone'><cite>NM:</cite> This is what I was trying to
say before: there's a question of what information is available
and what the application expectations are.</p>
<p class='phone'><cite>DC:</cite> It's a bad example of
extensibility.<br />
... The strong tag is a better example</p>
<p class='phone'><cite>DO:</cite> Maybe img isn't a good
example of a system, but it's a good example of a particular
set of choices<br />
... We can point out the flaws later.</p>
<p class='phone'><cite>DC:</cite> I think img is a much better
example of backwards compatibility</p>
<p class='phone'><cite>NM:</cite> I'm a little concerned about
the first GPN: fowards-compatibility requires extensibilyt
rule: Any language intended for forwards-compatible versioning
MUST have extensibility.<br />
... But Henry provided a counter example yesterday: a language
that gets smaller.<br />
... Ten features become five; and that first language had no
extensibility model.<br />
... I think you have to change from any to most.</p>
<p class='phone'><cite>DO:</cite> I'd like a MUST</p>
<p class='phone'><cite>DC:</cite> Don't say should or must, say
"this is a pattern that is known to work well"</p>
<p class='phone'><cite>HT:</cite> If you anticipate your
language evolving by adding new features, then you need an
extensibility rule.</p>
<p class='irc'><<cite>DanC_lap</cite>> (agenda request,
sorta... I started exploring an alternative set of definitions
that re-package the accept/defined stuff. I didn't really
finish my exploration, but folks might find it interesting. I
guess I should have showed it to Noah during a break. I wonder
if it's worth meeting time)</p>
<p class='phone'><cite>DO:</cite> WS-Security does not allow
for forward compatibility; it allows extension but says you
must fault if you don't understand the extension.<br />
... And you need to say both parts; you have to provide
extensibility *and* you must say what it means when one is
encountered.</p>
<p class='phone'><cite>NM:</cite> Many languages are understood
in terms of "the stuff I understand" and "this other
stuff"<br />
... Ian's earlier example of "banana" tags was a good example.
They get added to the DOM, they get styled by CSS. Etc. I could
have said that *all* these tags were in the language.</p>
<p class='phone'><cite>TV:</cite> When browsers implement XBL,
this will get even more interesting. You'll be able to provide
both style and interaction.</p>
<p class='phone'><cite>DO:</cite> It feels different to
me.<br />
... I think when people think about extensibility, they think
about designing a language with the things that they know and
they say very little about the other stuff.</p>
<p class='phone'><cite>NM:</cite> Part of our role is to
educate people; if what we discover with CSS and XBL is that
you might be fooling yourself, it's more subtle than you think.
We should think hard about telling that story.</p>
<p class='phone'><cite>TV:</cite> This is not much different
from moving code around.<br />
... You can say anything is allowed, then you can say that only
three namespaces are allowed, etc.</p>
<p class='phone'><cite>NM:</cite> Bananas can be styled
differently from Peaches; they aren't strictly synonyms.</p>
<p class='phone'><cite>DO:</cite> So items in the accept set,
not the defined text set, may have a certain amount of
processing associated with them.</p>
<p class='phone'><cite>NM:</cite> We're going in circles.</p>
<p class='phone'><cite>SW:</cite> Two questions: 1. do we have
a test for "MUST have extensibility"? Can we tell if a language
does or doesn't have extensiblity? And 2. what about any
language?<br />
... We've been talking about HTML 2.0 as a language and HTML
3.0 as a language, and also an abstract language called HTML of
which HTML 2.0 is a version.</p>
<p class='irc'><<cite>dorchard</cite>> Definition:
Extensible if the syntax of a language allows information that
is not defined in the current version of the language.].</p>
<p class='irc'><<cite>dorchard</cite>> from
versioning</p>
<p class='irc'><<cite>dorchard</cite>> prefix with
Languages are defined to be</p>
<p class='phone'><cite>SW:</cite> I asked if we have a test. Is
that a test?</p>
<p class='phone'><cite>DO:</cite> HTML is extensible because
banana isn't defined but it is allowed</p>
<p class='phone'><cite>NM:</cite> I'd approach it differently:
I'd say they were all in the language but it's extensible if a
more interesting definition can be provided later.<br />
... For example, he allows bananas and he allows CSS styling.
What could he do next?<br />
... Would it be compatible if they were changed to being block
by default?<br />
... I think you have to look at the individual languages to
answer some of these questions.<br />
... It seems to be that we can add attributes to existing
elements which is also a kind of extensibility.</p>
<p class='phone'><cite>SW:</cite> My second question was about
"any language". It seems to be talking about a family of
languages.</p>
<p class='phone'><cite>DO:</cite> I meant any in terms of any
language that you might want to design for forwards
compatibility.</p>
<p class='phone'><cite>SW:</cite> Ok, I see what you mean</p>
<p class='phone'><cite>DC:</cite> I started exploring an
alternative set of definitions that re-package the
accept/defined stuff. I didn't really finish my exploration,
but folks might find it interesting. I guess I should have
showed it to Noah during a break. I wonder if it's worth
meeting time<br />
... Nevermind. I don't have the bits.<br />
... It's on another machine.</p>
<p class='phone'><cite>SW:</cite> Worth going further?</p>
<p class='phone'><cite>NM:</cite> I'm starting to feel a little
overloaded, I wouldn't like to think this was my last chance to
comment.</p>
<p class='phone'><cite>SW:</cite> We could look at the XML
piece, or we could look at the tag soup work that Henry has
been doing</p><a name="action03" id="action03"></a>
<p class='irc'><<cite>scribe</cite>>
<strong>ACTION:</strong> NM to write up his paper comments on
extensibility and versioning [recorded in <a href=
"http://www.w3.org/2007/05/31-tagmem-irc">http://www.w3.org/2007/05/31-tagmem-irc</a>]</p>
<h3 id="item05">Henry's work on tag soup</h3>
<p class='phone'><cite>HT:</cite> I thought instead of telling
the HTML WG that they should describe HTML 5.0 declaratively, I
should just do it myself.<br />
... I think what we want is "formalized tidy", but tidy is just
a bunch of C code.<br />
... John Cowan's tagsoup is as close as we get.<br />
... Tagsoup consists of two parts: a table driven scanner
(tokenizer). It has a fairly nice declarative interface.<br />
... The scanner includes some ability to do fixup.</p>
<p class='phone'><cite>TV:</cite> I second what Henry says;
I've looked at the code and it's very nice.</p>
<p class='phone'><cite>HT:</cite> The second thing you get is
an improved sequence of angle brackets and text but not yet a
balanced set of start/end tags.<br />
... The second half of tag soup as its written takes a fairly
complicated description of the language, in terms of ancestry
and other things, which leaves out a bunch of stuff (like
cardinality and sequencing) but adds a bunch of other
stuff.<br />
... And doesn't expose the connection between where you are and
what you do for recovery. They're welded into the code.<br />
... It recognizes a half dozen kind of problems, but the
responses are welded in. I wasn't terribly happy with
that.<br />
... I wanted to expose the fixup rules.<br />
... The markup for this is called PYXup which is something like
the ESIS output from sgmls, if you remember what that
was.<br />
... Tagsoup can be told to simply output the pyx stream instead
of performing the fixup.</p>
<p class='phone'>Some discussion of the examples from Henry's
Extreme Markup Languages 2007 paper</p>
<p class='phone'><cite>HT:</cite> I can reconstruct all the
things that tagsoup does with this model</p>
<p class='phone'><cite>TV:</cite> One question to ask is what
happens in cases like
<table><form><tr><td></form><td>...<br />
... What's your goal? To make something that's valid or to make
something that mirrors the behavior of current browsers.</p>
<p class='phone'><cite>HT:</cite> It has to be the latter.</p>
<p class='phone'><cite>TV:</cite> Right. But if you look at the
test cases, you'll find that you don't get a well-formed DOM in
some of these cases.</p>
<p class='phone'><cite>HT:</cite> There's no question that the
current code doesn't do enough. The trick, I think, is to allow
the recovery actions to be sensitive to annotations in the
grammar. Table and form are good examples of cases where you
need annotations.</p>
<p class='phone'><cite>TV:</cite> In the HTML discussion this
is tangled up with the script processing.<br />
... The folks who don't want declarative rules just don't agree
with some of the results that the fixup does, particularly in
the case where script mangles the DOM.<br />
... TeX has done a better job of this because you can change
the \catcode of characters.<br />
... In some sense, this is what script is doing. Knuth
describes this in terms of the mouth and the throat and the
gullet.<br />
... So some changes occur in the "mouth" so they don't get down
into the "stomach".<br />
... The whole formalism argument is going to be thrown out
unless script can be addressed.</p>
<p class='phone'><cite>HT:</cite> I don't feel too worried
about the 90% case of scripting because what the fixup works
with is a string of start-tag/end-tag tokens.<br />
... If you recognize the start script tag you can hand over
tokenizing to the script engine.</p>
<p class='phone'><cite>TV:</cite> But you also need to provide
the token stream you've already seen so that script can munge
it.</p>
<p class='phone'><cite>HT:</cite> Right. That's not the 90%
case.<br />
... Ian objected to "scripts must produce balanced tags", but
my next question would have been, can you live with scripts
that don't change the preceding tokens.<br />
... What I heard Ian say was, "if two browsers do it" it has to
be in.</p>
<p class='phone'><cite>TV:</cite> They are caught in a
hole.</p>
<p class='phone'>Some more casual discussion begins...</p>
</div>
<h2><a name="ActionSummary" id="ActionSummary">Summary of Action
Items</a></h2><!-- Action Items -->
<strong>[NEW]</strong> <strong>ACTION:</strong> NDW to note a
problem near webarch/#pr-version-info in the errata [recorded in
<a href=
"http://www.w3.org/2007/05/31-tagmem-irc">http://www.w3.org/2007/05/31-tagmem-irc</a>]<br />
<strong>[NEW]</strong> <strong>ACTION:</strong> NM to draft a
blog item on possible semantics of version identifiers for review and, pending creation of
a TAG blog mechanism, post it [recorded in <a href=
"http://www.w3.org/2007/05/31-tagmem-irc">http://www.w3.org/2007/05/31-tagmem-irc</a>]<br />
<strong>[NEW]</strong> <strong>ACTION:</strong> NM to write up
his paper comments on extensibility and versioning [recorded in
<a href=
"http://www.w3.org/2007/05/31-tagmem-irc">http://www.w3.org/2007/05/31-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 16:20:53 $
</address>
<div class="diagnostics"></div>
</body>
</html>