TAG

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