- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Thu, 23 Mar 2006 16:24:26 +0000
- To: www-tag@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 See http://www.w3.org/2006/03/21-tagmem-minutes.html - - DRAFT - TAG 21 Mar 2006 See also: IRC log Attendees Present Tim Berners-Lee, Dan Connolly, Noah Mendelsohn, David Orchard, Vincent Quint, T. V. Raman, Ed Rice, Henry S. Thompson, Norm Walsh Chair Vincent Quint Scribe Henry S Thompson Contents * Topics 1. Administrative 2. Security Workshop 3. New publications 4. metadataInURI31 * Summary of Action Items http://www.w3.org/2001/tag/2006/03/21-agenda.html Administrative vq: next telcon 28 March ht: Regrets for 28 March vq: Proposed scribe: DO, fallback, ER <noah> Regrets for April 4th, which is 2 weeks out. I'll be at the XML Schema WG meeting. vq: Additions to the agenda? ... Brief summary of security wkshp from DC, 5 minutes at the beginning <DanC> er... http://www.w3.org/2001/tag/2006/02/27_minutes.html has an encoding problem vq: F2F at Mandelieu, minutes at http://www.w3.org/2001/tag/2006/02/27_minutes.html, http://lists.w3.org/Archives/Member/tag/2006Feb/att-0023/27-tagmem-minutes.htm http://www.w3.org/2006/03/03-tagmem-minutes.html vq: No further comments. . . first part approved <DanC> (I prefer that the minutes of that meeting all live in http://www.w3.org/2001/tag/2006/02/ ) danc: Should we have cross-links? <DanC> +1 approve, amended as VQ sees fit for hypertext-happiness vq: I'll copy and make links. . .anything else? OK, 2nd part approved ... 3rd part? er: needs a list of those present vq: and regrets from HT <DanC> I nominate http://www.flickr.com/photos/ndw/108395140/ for the record of our Friday beach walk vq: I'll copy, and then tell DanC dc: And I'll obsolete the original vq: OK, part 3 approved, will add links everywhere, and from the agenda <DanC> (my blog entry http://dig.csail.mit.edu/breadcrumbs/node/92 about France) Security Workshop <DanC> http://www.w3.org/2006/03dc-aus-lga/swauth dc: Alan Kotok produced a good trip report, but it's team-only :-( ... OpenID (walked through at Edinburgh f2f), SXIP (covers more), both of these work by having a link from my homepage to an authetication server. OpenID use 'openid.server' as the relation, DICS use 'dix:/homesite' dc: standardizedFieldValues51 is relevant here <DanC> http://lists.w3.org/Archives/Public/www-tag/2006Mar/0038.html standardizedFieldValues-51, RDFinXHTML-35, endPointRefs-47, siteData-36 dc: Above is my message about this meeting -- InfoCard was also presented, it uses an EPR as a persona reference ... Very interesting workshop scribe: Lisa Dusseault (new area director from IETF) says there are three new internet drafts in this area which the TAG should be looking at <scribe> ACTION: ER to follow up and tell us the references [recorded in http://www.w3.org/2006/03/21-tagmem-irc] <DanC> lisa D's details to appear on http://www.ietf.org/html.charters/wg-dir.html soonish <DanC> Lisa Dusseault <lisa@osafoundation.org> http://www3.ietf.org/proceedings/06mar/agenda/dix.html <DanC> "this area" = http authentication dc: RDFinXHTML -- the upper part of SXIP includes exchange of claims, looked like subject/property/value, surely could be RDF ... Infocard has a similar claims exchange, maybe similar issue, maybe via SAML ... I keep missing Eve Maler's intro to SAML <raman> including expired SSL certs at TP:-) <noah> 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." ... That's certainly not reliable information, but it strongly suggests that Infocard optionally uses SAML. tbl: Any headline about a new direction? 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 [diversion about invalid HTML on the web. . .] 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 dc: No it doesn't -- extra elts and attrs are not normatively allowed, just acknowledged as a part of common practice <DanC> (and here begins the unbounded discussion that I warned about.) tbl: Why did we do that? hst: because the dtd was the only thing available 5 years ok for making normative statements nm: schema wg is hoping to provide some functionality here, in terms of new breed of wildcard tvr: but the lower-case s schema isn't the issue, it's what the browsers actually do that matters 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 <noah> 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. 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 nm: So xml schema provides for this, but it's single inheritance (substitution group) tbl: single-inheritance is a problem ... why did you do that? 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 <Zakim> 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-N. of Opera 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" ... 'you' is the banks ... They haven't even begun to notice validity as a desideratum tvr: They don't because they're not aware of any benefits dc: They need to be browbeaten about this, I intend to do so 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 vq: DC, please ask for agenda item next time if further thoughts occur <timbl> ... if the banks don't match the validator anyway New publications vq: DC has asked for help to get namespaceState draft published dc: I've been promised help froma team member on Wednesday nw: I'm confused, I thought we were just waiting for SoTD text, then it would be ready [hst, ndw, dc divert on minutiae of W3C publication process] metadataInURI31 <noah> Latest metadataInURI draft in date space: http://www.w3.org/2001/tag/doc/metaDataInURI-31-20030708.html vq: NM has been working on this . . . <noah> A summary of past work and some proposals for future work: http://www.w3.org/2001/tag/2006/02/metadatainURI31Roadmap.html 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 ... Long history, back to July 2003, Stuart Williams wrote a draft, lots of discussion, in spurts, thereafter ... I've picked this up, time to take stock er: I liked your summary a lot, thanks ... I also looked at the draft finding, there seem to be some suggestions, e.g. for removing parts 2 and 3 nm: Yeah, there was debate about that, I actually (from off the TAG at the time) thought they should stay ... We definitely need to get to grips with this from a fresh start ... I think we should not go back over the 100s of messages in the archives ... Are we happy that we should not do that? dc: Definitely not, there's far too much history for that to be cost-effective <Norm> What DanC said! :-) nm: Thanks, that's what I hoped ... Next question -- what should the draft really say? <noah> http://www.w3.org/2001/tag/2006/02/metadatainURI31Roadmap.html#NoahIdeas dc: I like the brevity of the four points, but I need a story. . . nm: Not to worry, this isn't the finding, it's just what the finding will end up with er: So this is close to the oriiginal finding -- how are they different? dc: Read them, please <Norm> I think these four points articulate a reasonable direction forward nm: [reads first bullet from http://www.w3.org/2001/tag/2006/02/metadatainURI31Roadmap.html#NoahIdeas] ... First bullet summarised: what you do in the privacy of your own server is your own business <DanC> (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) 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] dc: I know what this means, but I'm not convinced if anyone without my background with this issue would understand what it means <Zakim> ht, you wanted to ask a Dirk and Nadia question hst: Consider http://www.example.org/todaysnews/ hst: I'm concerned that this finding will be understood as saying the above URI can refer to a resource which is instructions for getting - From DanC's house to a local swimming pool without giving any grounds for complaint <Zakim> DanC, you wanted to offer "inference" and "risk" and such, rather than "Those with authority over resources" tvr: I agree that although it's very hard to pin down, people do have reasonable expectations based on what they read in URIs 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 risk <Zakim> noah, you wanted to probe on Henry/Raman example of side of bus common practice tvr: The ultimate conclusion of this is that we get nothing but humanly unreadable URIs, and surely that's wrong nm: The fourth bullet tries to address this issue -- there's always a cost to peeking inside URIs ... 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 tvr: I get the point for software, but it's mostly people who read URIs ... there's a funny kind of balance dc: to the extent that Consumers are licensed to peak into URIs, producers are constrained in how they produce URIs -- that improves usability, even if it isn't required <Zakim> timbl, you wanted to agree with raman but to say you are on your own if you can't guess it dc: The fact is that the minter has complete authority, per the current specs tbl: We do have to be careful ... I spend I lot of time looking at URIs, trying to find things that help me, e.g. understand what my bank is doing ... or c.f. the difference between MapQuest and Google map uris ... So on the one hand, it's dangerous, it may change, if you do you're on your own ... Perhaps we could [missed it] -- we have a convention, for instance the ? convention between forms and server software <noah> 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?) tbl: Or communities of users and producers may have a convention tvr: MapQuest is excellent example -- whatever we write should bias people towards making the URI useful ... MapQuest made a conscious decision, Google did too, in the other direction <noah> So, this seems to change Stuart's "A URI assignment authority MAY publish specifications detailing its URI assignment policies. " <noah> 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. " tvr: We should turn the emphasis towards guidance towards doing things in an extensible way tbl: Extensible? <noah> (I would word that in a less intimidating way, but is that the core thought?) tvr: Yes, because it encourages unexpected uses [scribe missed an example from tvr] <Zakim> 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 <Zakim> noah, you wanted to discuss specific proposal typed in above <raman> Note that what we're saying is similar to the Ruby On Rails philosophy of "convention over configuration". nm: Leaving aside reducing the intimidation factor, is the kind of thing tvr is looking for a change per that above addition of "SHOULD ...." <DanC> (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.) <raman> Here, the convention is that there is meaningful parts in the URL <noah> "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. " dc: tvr is going beyond this, saying "make them nice" 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." ... I'm concerned not to lose that ... So I should be careful w/o checkin for a spec when I see URIs on the side of a bus tvr: The MapQuest example may have a document which tells me how the URI is structured, or they may not (Google is starting to) ... But it often comes along after the fact tvr: So saying "before you publish something that people might use as an API, document it carefully" will just slow everythign down unnecessarily <noah> 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." <noah> I read that "no" as saying: assume they're opaque, don't peek. Round and round we go. <Zakim> ht, you wanted to talk about fragility of opaque URIs hst: Getting expectations from URIs, and then having them fulfilled, or not, is an important part of how the web works, in my opinion ... I'm concerned that the overall tone/focus of the finding should be positive, rather than negative dc: I'm somewhat sympathetic, but don't see how to get there without three years for writing a book 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 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 dc: we could focus on the software-brokenness story, and be careful and correct, but no-one would care a lot nm: .... documentation is good dc: In practice dictionaries and encyclopedias are already there, no additional documentation is needed <DanC> 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 nm: I think I could try to provide some concrete words, which might help us see whether we want to move this way tvr: Yes please 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 nm: I was just concerned that I didn't lose the history, I've been reassured vq: OK, that's a good place to stop for today, when can NM get us some more? nm: End of April vq: Confirm DO to scribe next week ... Suggest we come back to http://lists.w3.org/Archives/Public/www-tag/2006Mar/0009.html next week ... ER and TVR volunteer to review ACTION: ER and TVR to review draft finding on Authoritative Metadata http://lists.w3.org/Archives/Public/www-tag/2006Mar/0009.html dc: This is a revision of something we've seen before -- with two positive reviews we wouldn't need a long discussion Summary of Action Items [NEW] ACTION: ER to follow up and tell us the references [recorded in http://www.w3.org/2006/03/21-tagmem-irc] [NEW] ACTION: ER and TVR to review draft finding on Authoritative Metadata http://lists.w3.org/Archives/Public/www-tag/2006Mar/0009.html Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log) $Date: 2006/03/23 16:20:02 $ - -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFEIsu6kjnJixAXWBoRAnCRAJ41K+Ipmvj47Hzr7345+ofYcB+OEQCfYVAl wHOzWzWnSB+vTEJo20vdv5o= =ht01 -----END PGP SIGNATURE-----
Received on Thursday, 23 March 2006 16:24:39 UTC