17:57:17 RRSAgent has joined #tagmem 17:57:17 logging to http://www.w3.org/2006/03/21-tagmem-irc 17:57:24 Meeting: TAG 17:57:31 Chair: Vincent Quint 17:57:36 Scribe: Henry S Thompson 17:57:43 Scribe Nick: ht 17:58:20 http://www.w3.org/2001/tag/2006/03/21-agenda.html 17:58:20 TAG_Weekly()12:30PM has now started 17:58:27 +??P0 17:58:31 ht has changed the topic to: http://www.w3.org/2001/tag/2006/03/21-agenda.html 17:58:39 MoZ has joined #tagmem 18:00:00 Excuse me for asking, MoZ, but who are you? 18:00:05 Ed has joined #tagmem 18:00:23 On my way... 18:00:34 +Ed_Rice 18:00:53 raman has joined #tagmem 18:01:16 zakim, who is here? 18:01:16 On the phone I see ??P0, Ed_Rice 18:01:18 On IRC I see raman, Ed, MoZ, RRSAgent, Zakim, Vincent, DanC_lap, Norm, ht, DanC 18:01:24 noah has joined #tagmem 18:01:27 +DanC 18:01:30 +Vincent 18:01:40 +TimBL 18:01:42 zakim, please call ht-781 18:01:42 ok, ht; the call is being made 18:01:43 +Ht 18:01:46 ht i'm new to W3C and looking around 18:01:46 zakim, who is here? 18:01:46 On the phone I see ??P0, Ed_Rice, DanC, [INRIA], TimBL, Ht (muted) 18:01:51 On IRC I see noah, raman, Ed, MoZ, RRSAgent, Zakim, Vincent, DanC_lap, Norm, ht, DanC 18:01:59 +[IBMCambridge] 18:02:01 -TimBL 18:02:02 Zakim, ??P0 is raman 18:02:05 +raman; got it 18:02:11 zakim, [IBMCambridge] is me 18:02:13 +noah; got it 18:02:14 Guys, we have a stranger on the channel, I believe 18:02:28 MoZ, do we know you? 18:02:32 timbl has joined #tagmem 18:02:38 +TimBL 18:03:00 nevermind i'm going 18:03:05 Zakim, who is here 18:03:05 Vincent, you need to end that query with '?' 18:03:20 has a nice chat 18:03:25 Zakim, who is here? 18:03:25 On the phone I see raman, Ed_Rice, DanC, [INRIA], Ht, noah, TimBL 18:03:26 On IRC I see timbl, noah, raman, Ed, MoZ, RRSAgent, Zakim, Vincent, DanC_lap, Norm, ht, DanC 18:03:30 MoZ has left #tagmem 18:03:41 -Ed_Rice 18:03:50 +Norm 18:04:07 +Ed_Rice 18:04:12 Zakim, INRIA is Vincent 18:04:12 +Vincent; got it 18:04:18 Topic: Administrative 18:04:41 A new member of the XML working group 18:04:47 Mohammed Z 18:04:54 pha75-9-82-230-92-154.fbx.proxad.net 18:05:15 Mohamed Z 18:05:45 (I regret that we didn't manage to be more friendly to Moz) 18:05:50 zakim, who is on the call? 18:05:50 On the phone I see raman, DanC, Vincent, Ht, noah, TimBL, Norm, Ed_Rice 18:05:54 (me too) 18:07:00 vq: next telcon 28 March 18:07:09 ht: Regrets for 28 March 18:07:42 vq: Proposed scribe: DO, fallback, ER 18:08:11 Regrets for April 4th, which is 2 weeks out. I'll be at the XML Schema WG meeting. 18:08:25 vq: Additions to the agenda? 18:08:59 ... Brief summary of security wkshp from DC, 5 minutes at the beginning 18:09:33 er... http://www.w3.org/2001/tag/2006/02/27_minutes.html has an encoding problem 18:09:38 vq: F2F at Mandelieu, minutes at http://www.w3.org/2001/tag/2006/02/27_minutes.html, 18:09:44 http://lists.w3.org/Archives/Member/tag/2006Feb/att-0023/27-tagmem-minutes.htm 18:09:49 http://www.w3.org/2006/03/03-tagmem-minutes.html 18:10:49 Content-Type: text/html; charset=iso-8859-1 18:11:06 dorchard has joined #tagmem 18:11:25 (did you forget to spin around the 3rd time after sacrificing a chicken, ht? ;-) 18:11:41 DanC, that must be it 18:12:57 vq: No further comments. . . first part approved 18:14:11 (I prefer that the minutes of that meeting all live in http://www.w3.org/2001/tag/2006/02/ ) 18:14:47 danc: Should we have cross-links? 18:15:00 +1 approve, ammended as VQ sees fit for hypertext-happiness 18:15:13 vq: I'll copy and make links. . .anything else? OK, 2nd part approved 18:15:37 vq: 3rd part? 18:15:54 er: needs a list of those present 18:16:02 vq: and regrets from HT 18:16:52 I nominate http://www.flickr.com/photos/ndw/108395140/ for the record of our Friday beach walk 18:17:16 vq: I'll copy, and then tell DanC 18:17:33 dc: And I'll obsolete the original 18:18:33 q+ to ask if anybody else blogged 18:18:33 vq: OK, part 3 approved, will add links everywhere, and from the agenda 18:19:04 (my blog entry http://dig.csail.mit.edu/breadcrumbs/node/92 about France) 18:19:19 http://www.w3.org/2006/03dc-aus-lga/swauth 18:19:28 Topic: Security Workshop 18:19:51 dc: Alan Kotok produced a good trip report, but it's team-only :-( 18:21:05 ... OpenID (walked through at Edinburgh f2f), SKIP (covers more), both of these work by having a link from my homepage to an authetication server 18:21:45 OpenID use 'openid.server' as the relation, DICS use 'dics::server' [scribe unsure] 18:22:02 ... standardizedFieldValues51 is relevant here 18:22:06 http://lists.w3.org/Archives/Public/www-tag/2006Mar/0038.html standardizedFieldValues-51, RDFinXHTML-35, endPointRefs-47, siteData-36 18:23:03 ... Above is my message about this meeting -- InfoCard was also presented, it uses an EPR as a persona reference 18:23:18 ... Very interesting workshop 18:23:32 b 18:23:46 ... Lisa D (new area director from IETF) says there are three new internet drafts in this area which the TAG should be looking at 18:24:24 hst: Will you follow that up and tell us? 18:24:26 dc: No 18:25:49 Action: ER to follow up and tell us the references 18:25:53 lisa D's name to appear on http://www.ietf.org/html.charters/wg-dir.html soonish 18:26:21 Lisa Dusseault http://www3.ietf.org/proceedings/06mar/agenda/dix.html 18:26:52 "this area" = http authentication 18:27:54 dc: RDFinXHTML -- the upper part of SKIP includes exchange of claims, looked like subject/property/value, surely could be RDF 18:28:13 ... Infocard has a similar claims exchange, maybe similar issue, maybe via SAML 18:28:39 ... I keep missing Eve Maler's intro to SAML 18:29:04 including expired SSL certs at TP:-) 18:29:08 tbl: Any headline about a new direction 18:29:11 A Google search takes me to http://www.identityblog.com/stories/2005/07/05/IdentityMetasystem.htm , which says: "Negotiation is used to determine mutually acceptable technologies, claims, and requirements. For instance, if one party understands SAML and X.509 claims, and another understands Kerberos and X.509 claims, the parties would negotiate and decide to use X.509 claims with one another." 18:29:30 That's certainly not reliable information, but it strongly suggests that Infocard optionally uses SAML. 18:30:27 dc: 1) The padlock is _so_ broken, we should really fix that; 2) Banks are not losing so much from fraud that they are worried about that as such, but it fear about this is driviing folk away from online services and thus limiting the banks' enthusiasm for new services 18:30:59 [diversion about invalid HTML on the web. . .] 18:32:02 tbl: Versioning and what a language is -- HTML as a language isn't completely defined by its DTD, because that doesn't cover the fact that extra elements and attributes are allowed 18:32:11 q+ to recant... actually, HTML conformance _is_ relevant to the workshop, and was brought up by Charles M. of Opera 18:32:36 dc: No it doesn't -- extra elts and attrs are not normatively allowed, just acknowledged as a part of common practice 18:33:19 (and here begins the unbounded discussion that I warned about.) 18:33:19 tbl: Why did we do that? 18:33:38 hst: because the dtd was the only thing available 5 years ok for making normative statements 18:34:19 nm: schema wg is hoping to provide some functionality here, in terms of new breed of wildcard 18:34:49 tvr: but the lower-case s schema isn't the issue, it's what the browsers actually do that matters 18:35:03 q? 18:35:26 nm: Sure, but we started this passage wrt the goal of saying formally what the browsers already do, and that's what we're trying to provide 18:36:29 Tim is talking about describing abstract groupings like HTML blocks (div, element, etc.). Schema substitution groups exist today, and let you add things to existing blocks. 18:36:52 tbl: CSS is an interesting point in this regard -- refers to abstract classes of elements, e.g. HTML-block, and specifies that title is not a block 18:37:22 nm: So xml schema provides for this, but it's single inheritance (substitution group) 18:37:40 tbl: single-inheritance is a problem 18:37:55 ... why did you do that? 18:39:01 hst: Because as the architecture was spec'd, allowing multiple subst group membership would have required multiple inheritance of types, and we didn't know how to do it 18:39:01 ack danc 18:39:01 DanC, you wanted to ask if anybody else blogged and to recant... actually, HTML conformance _is_ relevant to the workshop, and was brought up by Charles M. of Opera 18:39:29 +DOrchard 18:40:17 dc: Closing panel at workshop, browser people asked what they needed, the response from C M-N was "give me a spec. for the HTML you produce" 18:40:29 ... 'you' is the banks 18:40:52 ... They haven't even begun to notice validity as a desideratum 18:41:15 tvr: They don't because they're not aware of any benefits 18:41:38 dc: They need to be browbeaten about this, I intend to do so 18:42:15 tvr: They don't see the immediate value, and trying to get validity sometimes actually gets in the way of what they're trying to achieve 18:42:50 vq: DC, please ask for agenda item next time if further thoughts occur 18:42:53 ... if the banks don't match the validator anyway 18:43:01 Topic: New publications 18:44:02 vq: DC has asked for help to get namespaceState draft published 18:44:24 dc: I've been promised help from a team member on Wednesday 18:44:45 nw: I'm confused, I thought we were just waiting for SoTD text, then it would be ready 18:44:48 s/ a team member/a team member/ 18:46:10 [hst, ndw, dc divert on minutiae of W3C publication process] 18:46:24 Topic: metadataInURI31 18:46:25 Latest metadataInURI draft in date space: http://www.w3.org/2001/tag/doc/metaDataInURI-31-20030708.html 18:46:38 vq: NM has been working on this . . . 18:46:40 A summary of past work and some proposals for future work: http://www.w3.org/2001/tag/2006/02/metadatainURI31Roadmap.html 18:47:34 nm: Basic issue - -should the TAG say anything about using the structure of a URI to represent metadata about a resource, and given that anyone has done this, whether others should rely on it 18:48:05 ... Long history, back to July 2003, Stuart Williams wrote a draft, lots of discussion, in spurts, thereafter 18:48:16 ... I've picked this up, time to take stock 18:49:03 er: I liked your summary a lot, thanks 18:49:25 ... I also looked at the draft finding, there seem to be some suggestions, e.g. for removing parts 2 and 3 18:49:50 nm: Yeah, there was debate about that, I actually (from off the TAG at the time) thought they shoudl stay 18:49:58 s/shoudl/should/ 18:50:23 q+ 18:50:24 nm: We definitely need to get to grips with this from a fresh start 18:50:43 ... I think we should _not_ go back over the 100s of messages in the archives 18:50:49 ack danc 18:51:01 ... Are we happy that we should _not_ do that? 18:51:17 dc: Definitely not, there's far too much history for that to be cost-effective 18:51:18 What DanC said! :-) 18:51:31 nm: Thanks, that's what I hoped 18:51:42 ... Next question -- what should the draft really say? 18:52:10 http://www.w3.org/2001/tag/2006/02/metadatainURI31Roadmap.html#NoahIdeas 18:52:55 dc: I like the brevity of the four points, but I need a story. . . 18:52:57 q+ 18:53:11 nm: Not to worry, this isn't the finding, it's just what the finding will end up with 18:53:30 q- 18:53:38 er: So this is close to the oriiginal finding -- how are they different? 18:53:45 dc: Read them, please 18:53:48 I think these four points articulate a reasonable direction forward 18:54:41 nm: [reads http://www.w3.org/2001/tag/2006/02/metadatainURI31Roadmap.html#NoahIdeas] 18:55:08 nm: First bullet summarised: what you do in the privacy of your own server is your own business 18:55:29 s/[reads/[reads first bullet from/ 18:55:39 (I'm not comfortable with "Those with authority over resources" but I don't have a suggestion of something better; see earlier discussion of struggling to come up with an IRW paper) 18:56:07 nm: The second bullet is direct from Stuart's draft [reads 2nd bullet from http://www.w3.org/2001/tag/2006/02/metadatainURI31Roadmap.html#NoahIdeas] 18:56:17 q+ to ask a Dirk and Nora question 18:57:05 dc: I know what this means, but I'm not convinced if anyone without my background with this issue would understand what it means 18:57:31 ack ht 18:57:31 ht, you wanted to ask a Dirk and Nora question 18:57:55 http://www.example.org/todaysnews/ 18:57:56 s/Nora/Nadia/ 18:59:07 q+ to offer "inference" and "risk" and such, rather than "Those with authority over resources" 19:00:13 q+ to probe on Henry/Raman example of side of bus common practice 19:00:58 hst: I'm concerned that this finding will be understood as saying the above URI can refer to a resource which is instructions for gettting from DanC's house to a local swimming pool without giving any grounds for complaint 19:01:02 q+ to agree with raman but to say you are on your own if you can't guess it 19:01:04 ack danc 19:01:04 DanC, you wanted to offer "inference" and "risk" and such, rather than "Those with authority over resources" 19:01:38 tvr: I agree that although it's very hard to pin down, people _do_ have reasonable expectations based on what they read in URIs 19:02:29 dc: I'm unhappy with putting the blame on "Those with authority over resources", I'd rather say that anyone who sniffs inside URIs does so at _their_ own refs 19:02:56 ack noah 19:02:56 noah, you wanted to probe on Henry/Raman example of side of bus common practice 19:02:57 tvr: The ultimate conclusion of this is that we get nothign but humanly unreadable URIs, and surely that's wrong 19:03:32 nm: The fourth bullet tries to address this issue -- there's always a cost to peeking inside URIs 19:04:44 ... This is a piece of the puzzle, but focusses on the risk for software, but that's an valid point -- software will be very fragile if it relies on being able to unpick URIs for substantive purposes 19:04:52 TVR: yes, I agree if you bake bizzare assumptions into software, you've got a problem. 19:05:15 tvr: I get the point for software, but it's mostly _people_ who read URIs 19:05:23 ... there's a funny kind of balance 19:05:54 q? 19:06:02 dc: Consumers are licensed to peak into URIs, producers are constrained in how they produce URIs -- that improves usability, even if it isn't required 19:06:15 ack timbl 19:06:15 timbl, you wanted to agree with raman but to say you are on your own if you can't guess it 19:06:20 ... The fact is that the minter has complete authority, per the current specs 19:06:49 tbl: We do have to be careful 19:07:13 ... I spend I lot of time looking at URIs, trying to find things that help me, e.g. understand what my bank is doing 19:07:21 s/Consumers are licensed/to the extent that Consumers are licensed/ 19:07:32 ... or c.f. the difference between MapQuest and Google map uris 19:07:56 ... So on the one hand, it's dangerous, it may change, if you do you're on your own 19:08:27 ... Perhaps we could [missed it] -- we have a convention, for instance the ? convention between forms and server software 19:08:45 I agree with what Tim is saying. I'm curious, in terms of the consumer's risk: aren't the issues already covered by Stuart's draft (modulo risk that I'd make things worse when rewording?) 19:08:48 ... Or communities of users and producers may have a convention 19:08:54 q+ to add: where the provider wants to make it crystal clear, and where they want to obfuscate they will do what th edo 19:09:47 tvr: MapQuest is excellent example -- whatever we write should bias people towards making the URI useful 19:10:05 ... MQ made a conscious decision, Google did too, in the other direction 19:10:10 So, this seems to change Stuart's "A URI assignment authority MAY publish specifications detailing its URI assignment policies. " 19:10:36 to "A URI assignment authority MAY publish specifications detailing its URI assignment policies, and indeed SHOULD do so when users are likely to benefit from being able to understand the metadata. " 19:10:41 ... We should turn the emphasis towards guidance towards doing things in an extensible way 19:10:50 tbl: Extensible? 19:10:52 (I would word that in a less intimidating way, but is that the core thought?) 19:11:03 tvr: Yes, because it encourages unexpected uses 19:11:24 q+ to discuss specific proposal typed in above 19:11:27 [scribe missed an example from tvr] 19:11:31 ack rama 19:11:31 raman, you wanted to add: where the provider wants to make it crystal clear, and where they want to obfuscate they will do what th edo 19:11:45 ack raman 19:12:07 q+ to talk about fragility of opaque URIs 19:12:14 ack noah 19:12:14 noah, you wanted to discuss specific proposal typed in above 19:13:01 Note that what we're saying is similar to the Ruby On Rails philosophy of "convention over configuration". 19:13:12 nm: Leaving aside reducing the intimidation factor, is the kind of thing tvr is looking for a change per that above addition of "SHOULD ...." 19:13:13 (boy, it would be nice to discuss usability, robustness, even aesthetic issues along with software-broknenness-level issues. But now it feels like a book.) 19:13:32 Here, the convention is that there is meaningful parts in the URL 19:13:39 "A URI assignment authority MAY publish specifications detailing its URI assignment policies, and indeed SHOULD do so when users are likely to benefit from being able to understand the metadata. " 19:14:19 dc: tvr is going beyond this, saying "make them nice" 19:14:45 nm: The core of the finding has said "you're at risk if you make inferences for which you have no license in a spec." 19:14:56 ... I'm concerned not to lose that 19:15:35 ...So I should be careful w/o checkin for a spec when I see URIs on the side of a bus 19:16:19 tvr: The MQ example may have a document which tells me how the URI is structured, or they may not (Google is starting to) 19:16:31 ... But it often comes along after the fact 19:17:08 ack ht 19:17:08 ht, you wanted to talk about fragility of opaque URIs 19:17:09 ... So saying "before you publish something that people might use as an API, document it carefully" will just slow everythign down unnecessarily 19:18:57 Noah notes that we seem to have come a long way since the 2003 decision which appears to have been "Resolved: Accept issue matadataInURI-NNN with note that TAG thinks the answer is "no" and will explain what to do instead." 19:19:20 I read that "no" as saying: assume they're opaque, don't peek. Round and round we go. 19:19:53 hst: Getting expectations from URIs, and then having them fulfilled, or not, is an important part of how the web works, in my opinion 19:20:16 ... I'm concerned that the overall tone/focus of the finding is positive, rather than negative 19:20:43 dc: I'm somewhat sympathetic, but don't see how to get there without three years for writing a book 19:20:53 q+ 19:21:38 nm: So what do I do now, it feels to me that there's a shift in direction here, I'm prepared to try to respond to that, but not sure that's what the group wants 19:22:30 nw: I agree that there's a shift in emphasis, and I want to think about it a bit, but I'm comfortable to try to move a bit in this direction 19:23:43 dc: we could focus on the software-brokenness story, and be careful and correct, but no-one would care a lot 19:24:18 nm:.... documentation is good 19:24:42 dc: In practice dictionaries and encyclopedias are already there, no additional documentation is needed 19:25:18 rather: all the dictionaries and encyclopedias in the world are part of the contract between URI minters and URI consumers whether they like it or not 19:25:22 nm: I think I could try to provide some concrete words, which might help us see whether we want to move this way 19:25:22 ack dorchard 19:25:26 tvr: Yes please 19:26:30 do: Wrt is the TAG moving -- the TAG membership has evolved, this is a healthy example of this, doesn't mean we were wrong before, but here's a new perspective which should lead to a better finding 19:26:49 nm: I was just concerned that I didn't lose the history, I've been reassured 19:27:34 vq: OK, that's a good place to stop for today, when can NM get us some more? 19:27:38 nm: End of April 19:28:00 q+ to mention new draft coming 19:28:29 vq: Confirm DO to scribe next week 19:29:30 vq: Suggest we come back to http://lists.w3.org/Archives/Public/www-tag/2006Mar/0009.html next week 19:29:49 vq: ER and TVR volunteer to review 19:30:01 -raman 19:30:39 -DOrchard 19:30:40 dc: This is a revision of something we've seen before -- with two positive reviews we wouldn't need a long discussion 19:30:41 -Norm 19:30:42 -Ed_Rice 19:30:42 -Vincent 19:30:48 -TimBL 19:31:17 YADIS? 19:31:31 yes, Yadis 19:32:56 Yet another damned intermidable session? 19:33:56 ht, don't forget to generate the minutes 19:36:35 rrsagent, set logs world-visible 19:36:47 RRSAgent, stop