14:05:17 RRSAgent has joined #tagmem 14:05:25 RRSAgent, pointer? 14:05:25 See http://www.w3.org/2003/06/02-tagmem-irc#T14-05-25 14:08:31 Ian, hello? 14:09:52 zakim, call Ian-BOS 14:09:52 sorry, Ian, I don't know what conference this is 14:09:56 zakim, this is TAG 14:09:56 sorry, Ian, I do not see a conference named 'TAG' 14:10:05 Ian, we are NOT on Zakim 14:10:10 ian, dial direct 14:10:16 conf is not on zakim 14:11:26 yes 617-258-7910 14:12:15 Roll Call: SW, TB, TBL, NW, CL, IJ 14:12:42 Regrets: PC, DO 14:12:55 Missing: DC, RF 14:14:45 # Accept 27 May teleconference minutes? 14:17:06 Correction: Previous meeting 12 May. 14:17:13 No resolution on state of those minutes; held over. 14:18:20 Review of agenda: http://www.w3.org/2003/06/02-tag 14:19:06 Next meeting: Proposed 9 June (regular teleconf on Monday) 14:19:23 NW: Likely partial regrets (will be on West Coast) 14:19:33 Resolved: next meeting 9 June 2003 14:19:51 DanC has joined #tagmem 14:19:55 Next virtual teleconf scheduled for 19 June. Conflicts with DC, RF, SW, TB. 14:20:50 +DanC 14:20:54 =================== 14:21:00 Feedback from Budapest. 14:21:12 CL: I think the AC session went well. Gave AC reps an idea of what we do. 14:21:48 CL: I suspect they feel more comfortable about the TAG. 14:21:54 CL: We did two straw polls. 14:22:18 Member-only slides: http://www.w3.org/2003/Talks/AC-0520-TAG/12.svg 14:22:32 CL: I think AC said they wanted arch doc both better and sooner. 14:22:53 TBL: For that question, I think people wanted us to cover historic Web, Sem Web, Web services, ... 14:23:11 TBL: I think our best course is to give them what we've got when we've got it. 14:23:25 SW: What about feedback on RDDL doc? 14:23:40 TB: I've received queries from Robin Berjon about future of RDDL. 14:24:08 TB latest version: http://www.tbray.org/tag/rddl/rddl3.html 14:24:22 TB: Web3D folks interested in knowing about RDDL 14:25:15 agreed? 14:25:18 SW: I heard from IJ that at least one suggestion was to publish as a Note, then take it from there. 14:25:45 Roy has joined #tagmem 14:27:28 DC, IJ: I don't remember much feedback to TAG presentation at WWW2003. 14:27:37 I've been trying to get into the telecon... what is the passcode? 14:27:45 IJ: other ideas: 14:27:55 - Allow people to register as customers of an issue. 14:28:22 bugger 14:28:38 + RoyF 14:29:58 ======================== 14:30:21 [TAG looks at using VNC for collaboration during this meetnig] 14:31:14 xvncviewer -shared norman.walsh.name:1 14:32:47 Read-through of Arch Doc 14:33:06 http://www.w3.org/TR/2003/WD-webarch-20030326/ 14:33:20 NW: My goal here is to walk through doc with eye to finding show-stoppers for last call. 14:34:08 NW: In particular, look at section 4. 14:35:04 TB: I sent comments on section 4: http://lists.w3.org/Archives/Public/www-tag/2003May/0101.html 14:35:15 [Lots of people read TB's proposal] 14:35:17 DaveO has joined #tagmem 14:35:34 NW: I agree work with TB on getting this written. 14:37:12 [TAG gives up on vnc for now] 14:37:24 + DO 14:37:50 CL: Section 4.3 Presentation/Content/Interaction is misplaced. 14:37:57 TB: There is content in the draft on this section. 14:38:07 TB: I thought it could be made to all out of 4.2.2 of my proposal. 14:38:17 TB: I wonder whether related to final form/re-usable. 14:38:25 CL: I've been working on a draft finding on this topic! 14:38:55 CL summarizes broadly: We seem to be making the arch doc more a summary doc and pointing to findings for detail. 14:39:05 NW: Seems reasonable to move content/presentation to 4.2.2 14:39:26 TB: I am willing to draft section 4 by end of week. 14:40:01 Looking at http://lists.w3.org/Archives/Public/www-tag/2003May/0101.html 14:41:47 Reviewing TB Draft: Open endedness 14:41:47 tim-mit has joined #tagmem 14:43:47 see also: QA spec guidelines 14:43:54 CL: add attention to authoers needs 14:44:12 that was me, actually, not that it matters 14:44:43 CL said 'availability of test suite' (and implementation report) 14:44:46 TBL: Under 4.1.1 - formal specification/machine readable form 14:45:01 QA Framework: Specification Guidelines 14:45:01 W3C Working Draft 10 February 2003 http://www.w3.org/TR/qaframe-spec/ 14:45:15 TB: that's what I'd intnded with attention to programmers' needs 14:46:05 DO: Want to push back on the need for 4.1.1 on the basis that this is generic good spec wrinting characteristics 14:46:28 CL: In think its useful and should be expanded. 14:46:54 TBL/DC: The QA activity covers this. 14:47:10 TB: Could go either way. 14:48:07 CL: 14:48:33 TB/CL: Does give us a place to put the error handling thing. 14:49:08 TB: Want to avoid the 'debacle;' of RDF rewriting their own BNF for XML. 14:49:26 re - if XML, defined at the Infoset level 14:49:47 you mean XPath level? 14:50:16 make some of these 'good practice notes' 14:52:07 TB:Action: write up a first draft of section 4 of Arch doc base on email: http://lists.w3.org/Archives/Public/www-tag/2003May/0101.html 14:52:54 PDF is better than PNG 14:52:59 gtom the point of view 14:53:11 [discussion of terms for 4.2.2] 14:53:26 Discussion of Semantics v Presentation 14:53:45 from the point of view that you can index it, cut and paste text to a certian extent. 14:55:06 CL: I'm working on a finding contentPresentation-26. Want to be sure we're headed in the same direction. 14:55:43 ah! 2 bits of writing. I see now. 14:55:52 TB: I'm happy draft the whole section, and I'm happy to accept some paragraphs on Content/Presentation from Chriss 14:56:50 pointer to finding? 14:56:55 TB: Makes sense to move 4.2.3 under 4.2.2 14:57:25 DO: Extensibility issues? Composable or reusable bit? 14:57:57 file:c:\cygwin\home\Chris\w3c\WWW\2001\tag\doc\contentPresentation-26-20030602.html 14:58:15 oops 14:58:17 DO: Concrete example: Schema restriction if designing for extensibility. Deterministic/non-deterministic content models 14:58:54 DO: Two types of composability: "backward compatible forward revision". 14:59:03 CL: Sounds more like interop 14:59:40 TB: Propose DO submits a couple of paragraphs to the group. 14:59:47 Backward compatability is an interesting discussion but big and long. 14:59:50 related issue for 4.2.3 is http://www.w3.org/2001/tag/open-summary.html#mixedUIXMLNamespace-33 14:59:51 DO: Agrees 14:59:52 q+ 15:00:31 Action DO: Write up a couple of paragraphs on extensibility for section 4. 15:01:51 TBL: Designing languages for extensibility and backward comaptibility is very complicated. Maybe we need to get back to what URI's meand 15:02:03 s/meand/mean 15:02:23 q+ 15:02:51 TBL: ... 1st thing we have to do is document 'how things work'. 15:02:57 q+ 15:03:03 ack tim 15:03:17 q+ 15:03:32 ack Dave 15:03:58 - Extensability is a good thing 15:04:20 - If you use it distinuguish optional from mandatory extension 15:04:22 DO: Think TBL is saying versioning is hard... shouldn't go there (for now)... 15:04:34 - For RDF, OWL provides powerful forwrad compatability tools 15:04:43 ack chris 15:04:47 q+ 15:04:52 TB: Yep.. versioning is hard, multi dimensional and needs to be designed in up front. 15:05:02 DO: 15:05:15 DO: Don't tyou think there are sepcific features for this? 15:05:20 DO: Don't you think there are features in W3C specs to deal with this? 15:05:23 TB: Anything defined in XML is more extensible/flexible 15:05:54 q+ 15:05:59 hmm... " Web Architecture: Extensible Languages" http://www.w3.org/TR/NOTE-webarch-extlang 15:06:07 q+ 15:06:24 q+ to say the 3 "-" things which he typed in above. 15:06:30 q+ timbray 15:06:51 SW: What expectations should we set wrt composablity of XML vocabs. 15:07:39 TB: Yes we should say something about what folks should consider if thery want their langauages to composable and extensible 15:08:39 TBL: Worth say that *if* you have extensibility to be able to distinguish between mandatory and optional extensionss 15:09:05 TBL: OWL/SemWeb can describe the relationships between versions of things. 15:09:46 yes, the mandatory/optional bit is an architectural point that The Director has found wanting in a spec in the past; let's please document it clearly to prevent the sort of uncomfortable end-game stuff that happened before. 15:10:02 DO: Ref to TBL design notes on mandatory/optional 15:11:29 DO: I have a number of constituents for help on versioning, extensibility and evolution - larger community than those interested in resolving httpRange14 15:11:34 ack tim 15:11:43 ack chris 15:11:53 ack daveo 15:12:14 DanC, we cannt hear you at all 15:12:26 Who dropped? 15:12:50 We heard dialtime, ian 15:12:55 We heard dialtone, ian 15:13:24 DC: Version in general is impossible... but maybe a few things worth saying. Leave space for versioning/extending; use URI as piviot points. 15:14:19 DC: All sorts of mechanisms in Schema... but I don't know if there are any that really generalise. 15:14:51 ... generalize to issues of web architecture. 15:15:39 q+ to talk about namespaces as opposed to namespace documents 15:15:49 ack danc 15:15:50 ack DanC 15:16:15 http://www.w3.org/TR/2003/WD-webarch-20030326/#format-specs 15:16:19 4.3.1. When to use XML 15:16:32 Looking at 4.3.1 in WebArch doc "When to use XML" 15:17:00 NW: Volunteered some text for 4.3.2 15:17:05 + Ian on land line. 15:17:49 CL: 4.3.2 starts of saying should use namespaces and then focusses on what should be in a namespace doc, rather than 15:18:20 talking about why ns's should be used. 15:18:39 NW: It's in the text I proposed. 15:18:58 4.3.5 Complex XML with references to TAG issues 15:19:08 binary would go into the proposed 4.2.1 Binary vs. Textual 15:19:08 CL: Move to ??? 15:20:05 TB: I think 4.4 is a little long; would try to boil down. 15:20:15 CL: 4.4.1 in existing doc is rubbish 15:20:30 CL: I am expecting to replace section on content/presentation 15:21:04 TB: 4.4.1 disappears. 15:21:26 4.4.1 is notes about what to talk about later. some of it is already talked about 15:21:31 NW: I hear proposal that, for the purpose of advancing doc to last call, abandon 4.4.1 and rely on people to resurface issues discussed there in a more concrete form if they want them addressed. 15:21:37 [No objections to that course of action] 15:22:10 CL: Not ready for www-tag yet. 15:22:44 CL: I can commit to having this ready for www-tag next week. 15:23:00 [NW 4.5 arch doc] 15:23:05 kill 4.5. Ideas and issues 15:23:16 NW: This is a laundry list; sounds like we would be inclined to throw 4.5 in bit bucket. 15:23:27 TB: I don't see good solution to xlinkScope-23, item 8. 15:23:44 TB: Not sure where in the arch doc this belongs. 15:24:21 TB: I propose - new section 4.5 in my draft outline - "Hyperlinking in Resource Representations" 15:24:34 q+ 15:24:42 DC: Perhaps earlier in section 4 would be better (than 4.5) 15:25:03 DC: Rationale - links are the most important architectural piece for the Web. Should be earlier 15:25:18 CL: We need to put into the proposed section a difference between a URI and a link. 15:25:23 q+ to say that we should keep the issues from 45. in general 15:25:29 ack Chris 15:25:29 Chris, you wanted to talk about namespaces as opposed to namespace documents 15:25:34 NW: How about just before TB's 4.2? 15:25:40 difference between a uri and a link needs to go in there 15:25:54 TB: Not convinced by DC; I think this document will not be accessed linearly. 15:26:05 ack Chris 15:26:17 ack timbl 15:26:17 timbl, you wanted to say that we should keep the issues from 45. in general 15:26:48 s/45/4.5 15:26:54 IJ: What are other homes for items in 4.5? 15:27:05 so we decided to remove 4.5 but first find suitable homes for each point and it s associated link to an issue 15:27:20 TB: Perhaps another top-level section on mime type being authoritative? 15:27:25 IJ: Is that part of protocols or formats? 15:27:41 CL: Maybe mime type stuff for beginning of section 4 15:27:50 CL: And maybe needs a section title (for first few paragraphs) 15:28:07 TB: I'll think of a title for that section. 15:28:25 need a name for the 'representation is mime metadata plus the actual bits' section 15:28:43 Action NW: Take a stab at proposed new 4.5, wherever it ends up. 15:28:49 5. Machine-to-machine interaction 15:29:06 TB: I propose we leave 5 skeletal and delete 6. 15:29:25 TB: I think we won't have time to do much on 5 and get 4 more baked. 15:29:29 just "Interaction", please 15:29:55 TBL: I think that 5 is not about multi-modal interaction. 15:30:17 CL: I think so too, but don't know where to put 5.1 DI and MMI 15:30:29 DC: Nothing in section 5 that I can't live without. 15:30:37 TB: I think 5.2 is valuable. 15:30:47 RF: It just looks weird. :) 15:30:59 5.1. Device Independence and Multimodal Interaction needs to go in a 'Human to Machine interaction' section 15:31:15 maybee, some aspexcts of linking would also go in that section 15:31:28 Web is not static, so we need to deal with interaction 15:31:28 TBL: If we had something saying "Don't make protocol stateful when you can make it stateless" that would be reasonable. 15:33:21 [Discussion of what is scope of work about which we can declare victory] 15:33:33 TBL: You can make the last call "complete" by listing sections that are not baked. 15:33:35 q? 15:33:52 q+ 15:33:57 DC: The scope should be stated at the beginning of the doc. Don't require reader to read chapter 5 and fall off edge of earth. 15:34:25 NW: Propose - (1) Delete section 5 and (2) state in scope of doc that we don't cover this (3) List a few issues that we don't cover. 15:34:30 DC: Don't leave it there as a place-holder. 15:34:53 DC: The document should be complete for its chosen scope. I wouldn't want to read highly polished text then unpolished text. 15:35:03 CL: I would like it to be clear that the scope is limited. 15:35:41 TB: I think that a placeholder section would have tutorial value, just to point out to reader that they don't have everything they need in this doc. 15:35:49 NW: What about moving 5 to a finding? 15:37:19 CL: Proposal - leave section 5 in place (arch issues about m-to-m interaction) [2] move 5.2 to 5.2 [3] move 5.3 to 5.2 and list open issues. 15:37:37 TBL: Sounds to me like scope of section 5 is (1) working of http and (2) web services 15:37:46 (Arch principles behind them) 15:38:22 TBL: (a) Web Services arch and (b) Message passing that supports REST model 15:38:34 TBL: Design (a) of HTTP and (b) use of HTTP POST 15:38:57 if 5 is called interaction then we need 5.1 machine-machine interaction (ws, etc) and 5.2 human-machine interaction 15:39:32 RF: 5 is about communication between two separable components of the architecture. 15:39:40 q+ timbray 15:39:42 q+ tbray 15:39:53 q- tbray 15:39:57 doh! 15:40:16 TB: I like the architectural tripod. 15:40:35 TB: I disagree with TBL - I think that interaction is qualitatively different and can be discussed separately. 15:40:54 TB: HTTP and Web Services models of interaction are what we would discuss here. 15:41:11 TBL: Interaction between client/server is done to create an information space view (quasi-static) to the user. 15:41:28 TBL: That illusion (reality!) is created by a bunch of http messages running back and forth. 15:41:43 TBL: We can talk about that, and we can talk about Web services 15:41:55 RF, CL: I would also add to that section - human/machine interaction (e.g., voice) 15:42:31 TB: I think that Human/Computer Interaction doesn't belong in section 5. I"m having a hard time thinking how hci issues fit into web architecture. 15:42:46 TB: I think the web arch should impose zero constraints on interaction from people. 15:42:47 q+ 15:43:01 CL: I disagree with TB on this point. 15:43:05 ack timbl 15:43:31 HCI and WS are different. 15:43:40 TB: I propose we create a new top-level section on Human/Computer Interaction 15:43:51 eek! new sections now? hmm... i thought we were trying to figure out which parts we could finish this summer. 15:44:03 RF: The reason that HCI is part of this is *latency*. 15:44:12 good point 15:44:16 RF: Latency is important because of HCI part. It's part of the notion of the arch of the system. 15:44:23 We are trying to figure out ho wto describe the scope of what he have done -- this involves enummerating things out of the current scope. 15:44:58 latency? 15:45:10 q+ 15:45:17 ack Roy 15:45:21 IJ: can we scatter HCI issues as rationale throughout the doc? 15:45:36 latency example - server-side imagemaps vs client-side imagemaps 15:45:40 TB: That makes sense; another example is transcribable URIs, or composability for formats. 15:45:50 TB: Maybe not a top-level section, but scattered throughout. 15:46:07 another latency example - 'getting a new html doc on every interaction' vs 'rollovers' 15:46:12 SW: Someone should take a close look at 5 and suggest an outline has TB has done for 4. 15:46:22 "y reducing the average latency of a series of interactions " - RF ch 5 15:46:40 ok 15:46:49 Tim: Propose we sjip section5 fornow 15:46:55 that was timBray 15:47:27 so we go to last call with a bipod - an architecture for a static, non-interactive web 15:47:32 DanC: Propose we remove section 5 for practicality. 15:48:36 STRAW poll 15:48:43 Stuart: section syaing work to be done 15:48:45 Norm: too 15:48:51 TBRary too 15:48:57 TimBL: abstain 15:49:09 DanC: Remove entirely 15:49:19 Chris: section saying work to be done 15:49:25 Roy: " " " "" " 15:49:33 DO: wrok to be done. 15:49:52 (Ian off teh call) 15:50:30 break?? 15:50:44 6:1 in favor of putting it in as a placeholder explaining what work needs to bedone. 15:50:46 I will take action item to fill-out section 5 15:51:03 HCI, HTTP internals and WS 15:51:11 must be convreed somewher in that lot. 15:51:14 -- timbl 15:51:28 within two weeks 15:51:40 Roy: I volunteer to write the placeholder section 15:52:33 Roy will be unavailable for TAG class Aug 30. 15:52:44 Zakim, remind us in 15 minutes to resume from break 15:52:44 ok, DanC 15:52:57 Zakim, room for 10? 15:52:57 sorry, DanC, not enough capacity right now to add a 10 person conference 15:53:22 Interetsing to see whether the Zakim really is full or overvooked. 15:53:26 booked 15:56:13 only 12 ports in use, per http://www.w3.org/1998/12/bridge/Zakim.html 15:55Z 16:03:30 Zakim is available since PPWG not meeting 16:07:44 DanC, you asked to be reminded at this time to resume from break 16:09:40 nobody here 16:09:53 here=? 16:10:03 the new number 16:10:05 I'm on 617-258-7910 16:10:11 Please let's move to zakmi 16:10:13 zakim 16:10:24 code 0TAG 16:10:25 zakim, dial chris-work 16:10:25 sorry, Chris, I don't know what conference this is 16:10:32 zakim, this is TAG 16:10:32 sorry, Ian, I do not see a conference named 'TAG' 16:10:35 zakim, list 16:10:35 I see WS_TF()12:00PM active 16:10:36 also scheduled at this time are PP_PPWG()11:30AM, XML_XSLWG()12:00PM, XML_QueryWG()12:00PM, TAG_()10:00AM, QA_QAWG()11:00AM 16:10:40 no your not ;-) 16:10:42 zakim, this is TF 16:10:43 ok, Ian 16:10:49 Just dailing in 16:10:50 zakim, this is TAG_() 16:10:50 sorry, Ian, I do not see a conference named 'TAG_()' 16:10:52 WS_TF()12:00PM has been moved to #ws-desc by Philippe 16:10:53 zakim, dial chris-work 16:10:53 sorry, Chris, I don't know what conference this is 16:10:58 zakim, this is not TF 16:10:58 sorry, Ian, I do not see a conference named 'not TF' 16:11:06 zakim, this is TAG 16:11:06 sorry, Ian, I do not see a conference named 'TAG' 16:11:13 zakim, this is 0TAG 16:11:13 sorry, Ian, I do not see a conference named '0TAG' 16:11:23 zakim, this is tag 16:11:23 ok, Norm 16:11:23 zakim, this is tag_ 16:11:24 Chris, this was already TAG_()10:00AM 16:11:25 ok, Chris 16:11:25 +??P3 16:11:29 zakim, dial chris-work 16:11:29 ok, Chris; the call is being made 16:11:30 +Chris 16:11:34 hooray 16:11:40 zakim, ??P3 is Roy 16:11:40 +Roy; got it 16:11:43 Ralph has joined #tagmem 16:11:45 zakim, who's on the phone? 16:11:45 On the phone I see Norm, Roy, Chris 16:11:52 Hi Ralph, zakim seems to be happy now. 16:11:57 zakim, what conference is this? 16:11:57 this is TAG_()10:00AM conference code 0824 16:12:05 zakim, call Ian-BOS 16:12:05 ok, Ian; the call is being made 16:12:06 +Ian 16:12:13 Ralph has left #tagmem 16:12:15 there is echo 16:12:37 -Norm 16:12:48 zakim, drop Ian 16:12:48 Ian is being disconnected 16:12:48 -Ian 16:12:51 +Norm 16:12:59 zakim, call Ian-BOS 16:12:59 ok, Ian; the call is being made 16:13:00 +Ian 16:13:04 zakim, drop Ian 16:13:04 Ian is being disconnected 16:13:04 -Ian 16:13:07 zakim, call Ian-BOS 16:13:07 ok, Ian; the call is being made 16:13:08 +Ian 16:13:14 zakim, drop chris 16:13:14 Chris is being disconnected 16:13:15 -Chris 16:13:48 + +1.703.502.aaaa 16:13:57 zakim, passcode? 16:13:57 the conference code is 0824, Chris 16:14:07 too late 16:14:19 +??P4 16:14:30 +??P6 16:14:40 zakim, ??P4 is me 16:14:40 +Stuart; got it 16:14:50 zakim, ??P6 is TimBray 16:14:50 +TimBray; got it 16:14:54 zakim, who's here? 16:14:54 On the phone I see Roy, Ian, Norm, +1.703.502.aaaa, Stuart, TimBray 16:14:55 On IRC I see timbl, Roy, DanC, RRSAgent, Stuart, Norm, Zakim, Chris, Ian 16:15:44 +DanC 16:15:55 ============== 16:16:02 Walkthrough of arch doc 16:16:28 http://www.w3.org/TR/2003/WD-webarch-20030326/ 16:16:31 [Section 1] 16:17:42 [On section 6] 16:17:46 IJ: Move these to better home. 16:18:36 IJ: This was meant to be factoring out. 16:18:45 RF: I think ok to repeat in each section. 16:19:20 yes, let's nix section 6. 16:19:36 Proposed: Nix 6.1. 16:19:47 [RF may or may not reuse this text] 16:19:52 Resolved: Nix 6.1 16:19:58 Resolved: Nix 6 16:20:28 -------------- 16:20:29 Abstract 16:20:52 DC: "When followed" unclear to me. 16:21:10 sdection 1: Interaction. Agents exchange representations via a non-exclusive set of protocols, including HTTP, FTP, and SMTP1 16:21:16 TB: See my comments on adding "efficient..." 16:21:17 is not actualy adressed 16:21:40 DC: I think it means to say "When Web Arch is followed...." 16:22:18 RF: I wouldn't say that I'm happy with the abstract. 16:22:32 NW: Sounds like DC's comment is editorial. 16:22:45 DC: I'll try to wordsmith offline. 16:22:56 DC: I think it's worth giving the tripod a few words in the abstract. 16:23:54 RF: The abstract should say "we organized" not that "we did it" 16:24:25 RF: I read the abstract and it seems wrong; I don't have a better counter-proposal right now. 16:24:50 TB: Tripod is mentioned in abstract.... 16:25:19 DC: I don't like "this document". Web architecture has three parts. 16:25:30 ============= 16:25:33 [Status] 16:26:07 TB: Update to say 1-4 in decent shape; 5 absent 16:26:22 SW: Also, section numbering is all wrong. 16:26:36 pls don't refer by section # alone. 16:27:05 -------------- 16:27:10 TOC: 16:27:15 IJ: Ok highlighting principles there ok? 16:27:16 TB: Yes. 16:27:18 DC: Don't know. 16:27:20 SW: Fine for now. 16:28:01 DC: Lost a lot - sentence disappeared. 16:28:04 RF: I prefer that approach. 16:28:15 RF: I prefer that over shortening the essence. 16:28:30 DC: So I'm not happy with it but don't have a replacement. 16:29:11 NW: I may comment on TOC at later date. 16:29:18 ------------- 16:29:24 1.1 Scenarios. 16:29:33 NW: I think that frag id discussion too confusing this soon. 16:29:41 NW: What about losing it from the scenario? 16:29:49 Zakim, who is here? 16:29:49 On the phone I see Roy, Ian, Norm, +1.703.502.aaaa, Stuart, TimBray, DanC 16:29:51 On IRC I see timbl, Roy, DanC, RRSAgent, Stuart, Norm, Zakim, Chris, Ian 16:30:14 +TimBL 16:30:26 TB: Agree to lose the frag id part. 16:30:52 RF: Because it's a scenario, just say "found the URI in a travel magazine." I like the fact that he has to transcribe the URI. 16:31:27 Proposed: Lost frag id from 1.1 scenario. 16:32:06 IJ: I propose picking up the scenario with frag id part in section on frag ids. 16:32:25 Proposed: 16:32:32 - Lost frag id from scenario in 1.1 16:32:42 - Dan finds URI in a printed magazine 16:33:00 - IJ to try to move frag id part of scenario to section on frag ids (picking up thread from intro) 16:33:08 Resolved: adopt these proposals. 16:33:31 NW: Propose TAG ftf meeting in Oaxaca. 16:34:54 q- 16:35:10 IJ: Running with idea, continue scenario, e.g., in section on deep linking (e.g., DanC has to subscribe to magazine to get info) 16:35:22 RF: Highlight when you are talking about the scenario. 16:35:47 DC: I have heard TBL and RF say that have issues with terminology. 16:35:54 (e.g., "resource") 16:35:59 DC: Is the current 1.1 ok? 16:36:02 RF: Seems fine to me. 16:36:36 DC: Fix inconsistency between agents and "resources". 16:36:39 TB: Lose the bold. 16:37:06 http://llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.com/ 16:37:06 TBL: I don't think that the text in 1 is affected by the TBL/RF issues. 16:37:17 TB: Use consistently. 16:37:23 use 16:37:37 DC: It's useful for me to have distinctive markup for term definitions. 16:38:10 ... and have the glossary point to them 16:38:26 IJ: Spec source in xhtml for now. 16:38:43 TB, DC: Highlight first instance of terms. 16:38:51 (And be consistent) 16:39:03 dfn 16:39:07 TB: Hyperlink back to first instances. 16:39:37 over-linked spec problem 16:39:52 I don't need all uses of a term marked up 16:41:14 Bets practice: When chosing a data format, it is best to chose one which is defined by a spec designed in the light of an architecture document which has been publiched using a namespace which supports multiple link destinations. 16:41:17 ;-) 16:41:24 ======================== 16:41:27 Section 2 16:42:19 2.1 16:42:23 TB: Drop "Some of the principles, practice, etc. may conflict with current practice, and so education and outreach will be required to improve on that practice. " 16:43:13 NW: Could be 1.2 16:43:19 DC: Prefer under section 1 16:43:38 TB, IJ: Don't feel strongly. 16:43:55 TB, DC: Keep scenarios up front. 16:43:55 NW: concerned that the scenario device may become too chatty for a normative spec 16:44:05 TB: I'd moderately prefer to keep a top-level section. 16:44:11 prefer 1.x, don't care over much 16:44:43 Remain top-level section: TB, IJ both mildly 16:44:47 STRAW Poll: 16:44:50 i think we have more important things to worry about 16:45:06 Subordinate: SW, NW, 16:45:15 Go with majority: CL, TB 16:45:17 suboridnate. 16:45:20 subordinate 16:45:22 subordinate 16:45:37 The subordinates have it 16:45:39 Resolved: subordinate 2. under 1, after 1.1 16:45:42 ------------- 16:46:00 add WSA 16:46:05 Resolved: Add WSA to list of arch specs in 2.2 16:46:43 TB: Furthermore, do we need the bulleted list at all? There will be other architectural things that bubble to the surface. This document is likely to be long-lived. 16:47:12 DC: I'd prefer to have citations to the actual specs : See charmod and the I18N Activity. 16:47:13 q+ pointers to specs works for me' 16:47:40 TBL: Create a references section and link down to that. 16:47:43 q? 16:47:45 Proposal: 16:47:48 - Mention Web services 16:47:55 - Link to references section in bottom of doc. 16:48:03 Other specifications in eth area of acc'y, di, and i18n apply [13-19]. 16:48:06 [Consensus around that] 16:48:39 ===================== 16:48:47 3. Identification and resources 16:49:20 RF: Having just rewritten intro to URI spec; need to sure that section 3. consistent with it. 16:49:23 I started reviewing RFC2396bis; my main comment at this point is: wow! lots of work went into the revision! 16:49:26 IJ: I read RFC; like it. 16:49:50 +DOrchard 16:49:52 RF: I've had positive comments only on the definitions of URIs, resources. 16:49:55 q+ to talk about opacity 16:50:07 ack danc 16:50:08 DanC, you wanted to confirm terminology in section 1 and to ask about losing bold 16:50:28 http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html 16:50:37 rev 2002? ok 16:50:45 RF: I propose that we refer to the new document (rev-2002)... 16:51:10 Proposed: Refer to new URI spec (draft). 16:51:19 TB, NW, RF, IJ: Ok to point to this draft. 16:51:51 draft-fielding-uri-rfc2396bis-0x 16:52:16 TB: Yes, I think it's ok to point to an internet draft on this one. Tell people it's a draft in progress. 16:52:31 CL: Ok, I'm happy to point to existing RFC2396 and say that it's being revised. 16:52:45 CL: Point to both. 16:52:47 q+ 16:53:08 http://www.apache.org/~fielding/uri/rev-2002/issues.html 16:53:08 TBL: We can call out an Internet Draft, even if it's not a standard. 16:53:51 TB: People are far-better served by RFC2396bis. 16:54:22 q? 16:54:35 q- 16:55:30 q+ 16:55:52 Can we please just refer to it as [URI] inside spec, and use references to indicate which one. 16:56:01 TBL: Suggest referring to rfc2396bis and in references section, indicate that this is an update.. 16:56:24 q? 16:56:30 ack Chris 16:56:30 Chris, you wanted to talk about opacity 16:56:31 DaveO has joined #tagmem 16:56:33 q+ 16:56:37 q+ 16:56:50 I suggested that we point to the one whose concepts and vocabulary we use in our doc. 16:57:42 note the currently endorsed standard has a number of differences and we refer to and uyse th terminolgy of th ebis draft indicated. 16:57:43 IJ: I second referring to [URI] and telling the story in the refs section. 16:57:51 ack Ian 16:57:52 I am happy to point to it, and to say why; I object to saying that it superceeds the RFC because it does not 16:58:02 q+ 16:58:04 IJ: Seems ok to have docs and their refs evolve in tandem, even if drafts now. 16:58:07 the maturity axis and the we-like-it axis are orthogonal 16:58:09 ack Roy 16:58:13 ack DaveO 16:58:31 q+ to talk about opacity 16:58:58 DO: When do specs start referring to draft specifications. What is relation with, e.g., IRI spec references from other W3C docs? 16:59:25 RF: As an IETF writer, as long as we are not defining a technology standard (that would depend on others), we can refer to whatever we want. 16:59:45 DO: If Arch Doc refers to 2396bis, won't others do so as well? 16:59:59 DO: I agree that there is a diff between arch doc and a protocol/format spec. 17:00:00 ok so we can say that we should refer to IRI on the same basic, because its better .... 17:00:12 i thought I heard consensus: PROPOSED: "defined by [URI]" where [URI] points to http://www.apache.org/~fielding/uri/rev-2002/issues.html and explains its relationship to RFC2396 17:00:18 RF: We do set precedent in some senses, but we shouldn't refer to JUST RFC2396. 17:00:25 q+ re sequnec fo RFCs 17:00:26 RF: The technology is defined by a sequence of specifications. 17:00:35 q+ to re sequnec fo RFCs 17:00:58 RF: My suggestion is to say in web arch that URIs are defined by "The URI specification". In Refs refer to both RFC2396 and the current effort to revise it. 17:01:18 q? 17:01:25 ack Chris 17:01:25 Chris, you wanted to talk about opacity 17:01:56 http://www.example.com/oaxaca#weather 17:03:11 q+ 17:03:37 CL: Say in section 3 (w.r.t the scenario) that the URI COULD HAVE BEEN something else. Tie opacity into scenario. 17:04:51 ack timbl 17:04:51 timbl, you wanted to re sequnec fo RFCs 17:05:01 http://www.tomzap.com/climate.html 17:05:16 we can move on 17:05:25 Resolved: "Create [URI] and deal with this in refs" 17:05:35 Proposed: 17:05:39 say http://www.example.com/oaxaca.weather could have been http://sdfh.example.com/45j6w45j6l34k62lk46 17:05:40 - Tie in opacity to scenario 17:05:52 - Drop a reference to Stuart's finding. 17:05:54 or even, confusingly, example.com/manchester 17:06:38 q+ TBray 17:06:41 q+ timbray 17:06:44 ack Ian 17:06:47 ack tbrya 17:06:49 ack tbray 17:06:52 ack timbray 17:07:22 TB: Delete "The term "resource" encompasses all those things that populate the Web: documents, services ("the weather forecast for Oaxaca"), people, organizations, physical objects, and concepts. " 17:07:39 TB: (from this paragraph) 17:08:43 IJ: I propose moving opacity to another para; keep first para about resources. 17:08:45 q? 17:08:55 q+ 17:09:12 TB: Third paragraph - Delete technical usage note. 17:09:36 TB: Promote Editor's note to regular text. 17:09:56 TB: "TAG believes that internationization of URIs is architecturally important." 17:10:25 DC: "TAG considers". Say instead "IRIs are a valuable mechanism." 17:10:28 TB: 17:10:36 - IRIs are valuable work 17:10:41 - We think that are architecturally important. 17:10:57 RF: Create a "future directions" section for each leg of the tripod. 17:12:01 TB: "I18N of ids is important...here's where the work'd being done." 17:12:09 Propose: s/which the TAG considers to be a valuable mechanism /which are proposed as a mevhamism/ 17:12:22 Propose: s/which the TAG considers to be a valuable mechanism /which are proposed as a mechanism/ 17:12:25 DC: What's valuable is the work on internationalization of ids. 17:13:11 Proposal: (1) Internationalization of URIs is architecturally important (2) We appreciate the work going on over here. 17:13:35 DC: I'd prefer saying "Future directions: IRIs are an open issue." 17:14:09 q+ 17:14:17 CL: On previous grounds, why can't we point to IRI draft? 17:14:27 RF: I think DC's objection is to "it IS a good mechanism" 17:14:36 DC: I note that we have NOT made a decision on IRIs. 17:14:40 q+ to ask whether we are discussing the IRI issue now or not. 17:14:53 q- 17:15:12 DC: I'm not anywhere near closing IRIEverywhere-27 17:15:39 ack timbl 17:15:39 timbl, you wanted to ask whether we are discussing the IRI issue now or not. 17:15:47 well, I am fairly close so please educate me 17:16:18 TBL: I've written down some pieces about IRIs and ties to other specs. Quite complex. I think that a number of people on the call are as yet unsure about the implications. 17:16:21 what is it that we've almost agreed to, chris? 17:17:05 Proposal: (1) TAG considers interationalization of URIs is architecturally important (2) We appreciate the work going on related to IRIs. 17:18:23 i like that proposal 17:18:35 TB: I think that several people are discovering that when you try to write down what we actually think, consensus is further off than we think. 17:19:05 IJ: TBL, how close are you to sending your proposal to www-tag? 17:19:31 TBL: Not sufficiently complete. The gist of the proposal involves defining the types of comparisons you want to do. 17:20:10 [More discussion of the proposal...presumably to illustrate to CL some of TBL or DC's issues] 17:20:25 [...Canonicalization..] 17:20:46 TBL: TAG has not decided whether it wants to recommend that people use canonicalization. 17:22:41 Re-Proposal: (1) TAG considers interationalization of URIs is architecturally important (2) We appreciate the work going on related to IRIs. 17:23:57 DC: One of the most substantive discussion on IRIEverywhere occurred when I was not present. I didn't see "resolved" in minutes; so that's where I'm coming from. 17:24:03 (1) The tag recognises that the identitification relations implied by the URI and IRI specs are important and must be understood clearly before the architecture is defined in this area. 17:24:10 DC: Whatever we agree to on this issue, we need to be able to provide test cases. 17:24:18 ^counter proposeal by timbl 17:24:41 q+ 17:24:54 ack timbl 17:25:11 [Still discussion details of IRI issues] 17:25:22 q+ to point out errors 17:25:37 TBL: There is an implication in IRI specs that people will do comparisons. This means [scribe thinks he heard] that some string comparisons won't work. 17:25:47 it explicitly says you cant convert back and expect to get what you started with 17:25:52 yes, I did some fact-checking about timbl's claims about the IRI spec, and I couldn't confirm. 17:26:08 TBL: The IRI spec says loudly that URIs and IRIs are both valuable (and both can appear in an href) . That blows up strcmp 17:26:20 q? 17:26:27 it explicitly says to convert as late as possible and only to squeeze through hostile transports 17:27:21 straw poll please 17:27:32 Re-Proposal: (1) TAG considers interationalization of URIs is architecturally important (2) We appreciate the work going on related to IRIs. 17:27:39 "important" meaning: we accepted it as an issue. 17:27:52 IJ: We could jus tsay "we're following what's going on on IRIs" 17:28:05 Re-Proposal: (1) TAG considers interationalization of URIs to be architecturally important (2) We are following IRI work. 17:28:29 yes 17:28:29 NW: Yes 17:28:48 tim: no 17:28:52 TB by proxy: Yes 17:28:56 concur 17:28:58 do: yes 17:29:43 RF: My problem is "I18N of URIs" prefer "Localization of identifiers". 17:29:49 TB: I would prefer "I18N of identifiers" 17:30:14 RF: We are talking about localization here; they are only usable within a certain context. 17:30:45 no outcome. 17:30:49 localization is not the same as internationalzation 17:31:06 RF: I think we should have a section on future directions that talks about the IRI process and that's it. 17:31:29 CL: Why would we identify that as a future direction that we are interested in? 17:31:41 RF: We are interested in it; we need to find a solution to it. It's future work in the space of identifiers. 17:31:54 ack Chris 17:31:54 Chris, you wanted to point out errors 17:32:45 DO: We haven't tackled, e.g., use of identifiers in Web Services. 17:32:55 DO: CL's point is "what's the problem we are trying to solve" 17:32:58 ack DanC 17:33:10 DC: The fact that we accepted the issue is evidence that we think this is important. 17:33:28 editor of what? 17:34:50 IJ: I would be comfortable saying "I18N of ids is important; TAG is following IRI work." Not sure if would be part of "future directions" section. 17:35:24 [Moving on] 17:35:59 NW: Throughout the document, we use widely varying domain names. Readers might think there is significance to the domain names. Let's pick on. 17:36:24 use example.com consistently unless the domain name is actually significant 17:36:26 q+ 17:36:31 ack DanC 17:36:31 DanC, you wanted to suggest weather.example 17:36:41 DC: Use weather.example 17:36:46 ack danc 17:36:49 ack ian 17:36:53 weather.exampler.org or .com 17:37:07 1) Don't use real domains 17:37:17 TB: example.com better than example.weather. 17:37:27 TB: That looks weird to people. 17:37:40 s/example.weather/weather.example/ 17:37:52 ".example" is recommended for use in documentation or as examples. -- http://www.rfc-editor.org/rfc/rfc2606.txt 17:38:06 q+ 17:38:16 I support www.example.com/org/net 17:38:16 ack ian 17:38:27 DC: I can live with weather.example.com 17:38:31 Proposed: 17:38:42 - Remove "real domain" names (not example.*) 17:38:45 e.g. yahoo 17:38:47 yes. 17:38:58 I actually propose "example.com", not "example.*". 17:39:09 - Reduce overall number of sample domain names by hearkening back to scenario. 17:39:25 ================ 17:39:32 3.1. Comparing identifiers 17:39:40 TB: Take pointer to obsolete draft from para 4 17:40:32 TB: Section 6 of RFC2396bis improves on comparison text. I propose to strike 4th paragraph and say at end of first paragraph that discussed in [URI]. 17:41:44 Delete "Issue..." at end of 3.1 17:42:55 IJ: DO talked to me about URIs in Budapest about, e.g., 1-1 relationship between URI/Resource. 17:43:33 DO: I liked our Irvine discussion. 17:43:42 DC: We have a hello world example in a scenario. We don't have a picture yet. 17:44:19 SW: I could do a draft of an illustration. 17:44:28 DC: Two world views on one-to-oneness... 17:44:30 More than liked our irvine, found it useful though lots of it have faded from my memory, and my knowledge failed the test of trying to explain it. 17:44:43 RF: From discussion on URI mailing list, I'd be happy to just drop it. 17:44:52 3.1. Comparing identifiers http://www.w3.org/TR/2003/WD-webarch-20030326/#identifiers-comparison 17:44:59 ^that's what we're talking about, yes? 17:46:26 DO: I think that our discussion in Irvine should be captured here (two models) 17:47:12 DO: In the WSDL WG, they are looking at adding an attribute to services (proposed name "resource") to annotate a service description with a resource identifier for the thing that is behind the service. 17:47:28 DO: This would allow WSDL descriptions in multiple files but all related to the target resource. 17:47:30 "behind"? 17:47:50 DO: E.g., "David's printer". Web service A and Web service B (offered by company B) both relate to David's printer. 17:48:01 DO: The services are related because they both operate on David's printer. 17:48:44 q+ 17:48:57 device? 17:50:24 TBL: Not sure to me that for a Web service generally, there is only one attribute (e.g., behind). I think this is an application level vocabularly. 17:51:39 I would describe issue 14 as a semantic web issue 17:51:39 [Seems to be about httpRange-14] 17:52:15 DO: This about httpRange-14, and fleshing out the two world views in the arch doc. 17:52:16 q? 17:52:38 DC: I think that we can agree on the first picture, but that there are N views that conflict when you look at the details. 17:53:49 DO: Question we might want to answer - do two different URIs identify the same resource? 17:54:14 DO: i:identifiers, t:identifiers. 17:54:49 TBL: I think everyone agrees that you can have multiple ids for the same thing. 17:55:24 agree, lets carry on next monday 17:55:40 q+ 17:55:57 [Seems to be general agreement that today's discussion beneficial] 17:56:29 q+ 17:56:36 TB: I think that section 3 currently hits good 80/20 point. Not sure that we are missing some super important points before going forward. 17:56:42 DC: Consider my tree shaken. :) 17:56:45 80/20: 2nded. 17:56:48 s/DC/DO 17:56:57 q 17:57:05 ---------------- 17:57:11 Next session scheduled for 19 June. 17:57:20 SW: A number of people seem at risk on 19 June. 17:57:20 on plane 19 June 17:57:26 I am still ok for 19th 17:57:34 SW, RF, TB, DC at risk. 17:58:55 Proposed: 6 June. 17:59:03 TBL: I'm out of town 6 June. 17:59:13 Proposed: 9 June. 17:59:20 NW: Not sure I can arrange 4 hours. 17:59:26 TBL: 9 June is pentecost 18:00:11 proposal is 9:00-11:30 on monday? 18:00:17 Proposal: 3pm-5:30pm ET 18:00:31 okay 18:00:36 Yes: TB, CL, SW, DC, NW, IJ, TBL, RF 18:00:41 Yes: DO 18:00:49 resolved:! 18:00:55 Resolved: Cancel 19 June, meet as proposed 9 June 18:01:34 q- 18:02:22 Summarizing work for next week or so: 18:02:27 1) RF rewrite section 5 18:02:35 2) NW to rewrite section on hyperlinking 18:02:36 I will get Separation of semantic and presentational markup, to the extent possible, is architecturally sound 18:02:41 3) TB rewriting 4 18:02:44 ready for next wek 18:02:49 4) CL polishing up section on content/presentation 18:02:59 I'm working on HTML-in-RDF-nn 18:02:59 5) DO: Update issue 37 18:03:10 6) SW: Rewrites on opacity finding. 18:03:16 -Roy 18:03:18 7) IJ start working on rewrite of arch doc 18:03:23 ADJOURNED 18:03:25 -DanC 18:03:26 RRSAgent, stop