Draft minutes of TAG telcon 2006-03-21 for review

-----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