- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 30 Jan 2006 08:19:32 -0600
- To: www-tag@w3.org
hypertext: http://www.w3.org/2001/tag/2006/01/24-minutes
plain text follows...
[1]W3C
[1] http://www.w3.org/
- DRAFT -
TAG teleconference
24 Jan 2006
See also: [2]IRC log
[2] http://www.w3.org/2006/01/24-tagmem-irc
Attendees
Present
Noah_Mendelsohn, Ht, Vincent, TimBL, DOrchard, DanC, Roy
Regrets
Ed_Rice, Norm_Walsh
Chair
Vincent Quint
Scribe
Henry S. Thompson
Contents
* [3]Topics
1. [4]Administrative
2. [5]Security Workshop
3. [6]Reply from WS Addressing WG wrt epr-27
4. [7]Roy Fielding issue wrap-up
5. [8]xmlFunctions-34
6. [9]Principle of Least Power
* [10]Summary of Action Items
_________________________________________________________
Administrative
<scribe> Scribe: Henry S. Thompson
<scribe> ScribeNick: ht
VQ: Roy is at risk, we won't wait for him
NH, HT: Revised minutes will take a day or two, but will appear
VQ: Next telcon: HT, NM regrets for Schema f2f
... TBL regrets, RF regrets
... One more regret and I will cancel, but with 5 we will try to go
ahead
<DanC> I'm available to scribe 31 Jan
VQ: ER to scribe, DC fallback
<ht_> [11]Proposed agenda for today:
[11] http://www.w3.org/2001/tag/2006/01/24-agenda.html
VQ: Agenda agreed with Security Wkshp at the front and WSDL/RDF
added at the back
<ht_> [12]minutes of 10 Jan:
[12] http://lists.w3.org/Archives/Member/tag/2006Jan/att-0003/Jan102005.html
RESOLUTION: to adopt minutes 10 Jan
VQ: Activity summary due
<scribe> ACTION: VQ to prepare a summary in the next few days,
circulate to tag@w3.org for review, then go public depending on
feedback recorded in [13]http://www.w3.org/2006/01/24-tagmem-irc]
[13] http://www.w3.org/2006/01/24-tagmem-irc
VQ: TP starts in one month, no joint meetings yet scheduled. . .
... What opportunities are we at risk of missing?
DC: Like to talk to Compound Document WG. . .
DO: Working with Hoylen Sue on XML Schema versioning stuff, hoping
to work with Schema WG on that, also spooling up on our own
versioning work
... So want to ask Schema WG to take part to go over the use cases,
maybe get an updated draft finding in time
NM: XML Schema WG is not meeting at the Tech Plenary, meeting in
Florida next week instead
... But in fact at least HST, NM, MSM will be in Mandelieu
VQ: Formal meeting with CDF WG?
DC: I don't think a formal meeting is required, happy to just talk
informally
VQ: I wouldn't mind chatting with them. . .
<Zakim> noah, you wanted to mention binary WG
NM: I'd prefer to save formal meetings for times when we have formal
business to do, so perhaps not this time for CDF
<DanC> (Noah, did you say we've met with the CDF WG before? I don't
believe we have.)
HST believes we met CDF WG last year in Boston
NM: I don't have any particular item we need to talk to EXI about --
just pointing out that they're just starting up
<noah> EXI is meeting Thurs/Fri at the plenary, as I recall.
VQ: So doesn't sound like any formal meetings are required, but no
reason this can't change in the intervening month. . .
Security Workshop
<DanC> [14]W3C Workshop on Transparency and Usability of Web
Authentication 15/16 March 2006 New York City, USA
[14] http://www.w3.org/2005/Security/usability-ws/
DC thinking about turning his contributions to this group on
security into a position paper for this workshop
scribe: Digest authentication
DO: In our discussion about state, this has come up, and there's
some discussion about forms-based security
... taking over from http-based security, in my draft finding about
state
... Will find URI and paste here
DC: Haven't come up with a thesis statement for a paper
<Zakim> ht, you wanted to suggest a thesis
<dorchard> [15]Rough text for State finding 15 Oct
[15] http://lists.w3.org/Archives/Public/www-tag/2005Oct/0025.html
HST: "We already know what we need to do, why aren't we doing it?"
TBL: I'm interested, but I can't fit it in
<dorchard> The primary reasons for customized security are security
concerns, that
<dorchard> is wanting greater control over the security timing out,
and ease of use
<dorchard> concerns, particularly wanting direct control over the
look and feel of
<dorchard> the screens including helpful tips and links to forgotten
passwords.
TBL: I have a UK trip already scheduled for that week, which is a
shame
DO: Not in the same direction as HST's digest authentication
suggestion -- my thesis is we don't have what we need
TBL: Just display the name of the holder of the certificate in the
browser, half the phishing stuff would go away
DO: People want control of the look and feel, timing out, etc.
VQ: So, nothing for this group?
DC: I've got helpful input, all I was hoping for, not planning to
represent the TAG if I go
VQ: OK, nothing more to say
<DanC> aha! finally found it...
<DanC> [16]minutes of our security discussion
[16] http://www.w3.org/2001/tag/2005/09/20PM-minutes.html#item02
Reply from WS Addressing WG wrt epr-27
<ht_> [17]Reply from WS Addressing WG wrt epr-27
[17] http://lists.w3.org/Archives/Public/www-tag/2006Jan/0074.html
<noah> Our original proposed text:
<noah> Note: Web Architecture dictates that resources should be
identified with
<noah> URIs. Thus, use of the abstract properties of an EPR other
than
<noah> wsa:address to identify resources is contrary to Web
Architecture. In
<noah> certain circumstances, use of such additional properties may
be convenient
<noah> or beneficial, perhaps due to the availability of QName-based
tools. When
<noah> building systems that violate this principle, care must be
taken to weigh
<noah> the tradeoffs inherent in deploying resources that are not on
the Web.
VQ: WG has modified their document, asking for our feedback
<noah> Their proposal:
<noah> The Architecture of the World Wide Web, Volume One [AoWWW]
<noah> recommends [Section 2 of AoWWW] the use of URIs to identify
<noah> resources. Using abstract properties of an EPR other than
<noah> [destination] to identify resources is contrary to this
<noah> recommendation. In certain circumstances, such a use of
additional
<noah> properties may be convenient or beneficial; however, when
building
<noah> systems, the benefits or convenience of identifying a
resource using
<noah> reference parameters should be carefully weighed against the
<noah> benefits of identifying a resource solely by URI as explained
in
<noah> [Section 2.
<noah> The Architecture of the World Wide Web, Volume One [AoWWW]
<noah> recommends [Section 2 of AoWWW] the use of URIs to identify
<noah> resources. Using abstract properties of an EPR other than
<noah> [destination] to identify resources is contrary to this
<noah> recommendation. In certain circumstances, such a use of
additional
<noah> properties may be convenient or beneficial; however, when
building
<noah> systems, the benefits or convenience of identifying a
resource using
<noah> reference parameters should be carefully weighed against the
<noah> benefits of identifying a resource solely by URI as explained
in
<noah> [Section 2.
<noah> [Section 2.1] of the Web Architecture.
NM: We could quibble -- they toned things down a bit, we could push
back, but I think it's a straight yes-no call
DC: I can't see the difference . . .
... I've seen various drafts, can't tell the difference any more
TBL: I don't see anything worth fighting about there
DC: What about the example?
<noah> [18]Our note to WSA
[18] http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Oct/0004
HST: I think that was an illustration for their benefit, not
suggested for inclusion in their REC
... I think their proposal represents some positive movement on
their part, should accept with thanks
DO: +1
DC: I'd like to think a bit out loud about this before agreeing
... Were we trying to change the world, or just get some words in
the doc't
DO: I wanted us to change the world, in the direction of proposing
encoding of EPRs in URIs, but we haven't gone there
NM: [scribe missed some]
... DO helped us in E'burgh to see what some of the reasonable
motivations were for using EPR parameters for despatching
... So rather than just saying to WSAWG "don't go there", we decided
to try to get acknowledgement of the costs as well as the benefits
DC: Was there a GRID spec that uses EPRs?
NM, HST: WSRF
TBL: Worried none-the-less that we'll start seeing EPRs turning up
as the only identifier for some resources
DO: I still think we should push for EPR-in-URI work, maybe from WSA
WG, maybe with help from us
... Until that happens, as long as dispatching on QNames isn't
addressed, people will use EPRs
DC: Thanks, that has helped
<DanC> (I wonder if WS-RF is done, or still asking under review. I
get "done" vibes from [19]http://www.globus.org/wsrf/ )
[19] http://www.globus.org/wsrf/
NM: I'm concerned about the meta-question of scenarios in which a WG
is doing something (SOAP endpoints, WSDL component naming, WSA and
EPRs) where TAG feels more should be done -- how should we deal with
this
... I think this should be made more explicit in group charters, so
that they're not surprised/upset when we come to them
DO: I think we are there with XMLP, WSDL did the HTTP binding for
us, contributed to the schedule slip for WSDL2.0
... WSA is moving much faster, maybe that's because they _didn't_
take so much care about WebArch issues
<Zakim> DanC, you wanted to suggest 1st WG ftf as a time to expose
WGs to webarch, no just charter, and to think again about CDF, EXI
DO: Certainly agree that if we're going to enforce expectations
about WebArch on groups, we should signal that early
DC: Doing it via the charter is not clearly the best route, rather
get it in the culture at their first f2f. . .
NM: We could consider internal guidelines -- e.g. when people say
"Hey, do some RDF for that too", are you allowed to ignore that, or
is it obligatory, or . . .
... People are legitimately confused about how this all applies to
their WG
... They need help getting a consistent reading on this stuff
VQ: The agenda item is not about this general issue
<DanC> (yes, back to the proposal to accept this wording with
thanks.)
VQ: So how do we reply to their proposed text?
... I think I hear consensus that they've done a good thing, as far
as it goes.
RESOLUTION: We are satisfied with the text they propose to add
<scribe> ACTION: NM to convey this to the WSA WG [recorded in
[20]http://www.w3.org/2006/01/24-tagmem-irc]
[20] http://www.w3.org/2006/01/24-tagmem-irc
HST: Perhaps the meta-topic would be a good agenda item for the f2f
Roy Fielding issue wrap-up
VQ: Roy has left the call. . .
<ht_> [21]RF's pending actions:
[21] http://www.w3.org/2001/tag/actions_owner.html#RF
<ht_> [22]Roy's summary of his situation
[22] http://lists.w3.org/Archives/Public/www-tag/2006Jan/0073.html
VQ: wrt metadataInURI-31, no progress, RF suggests to drop the
action
... NM was involved too -- Noah?
NM: I've been trying to uncover the history, I get added to this
late in the game, don't really know the history
... Haven't made any progress -- we should assume it has fallen
through the cracks
... I would prefer to get off the hook on this to focus on other
issues on my plate
DC: I'm torn about this
TBL: Related to URIGoodPractices-40
<noah> [23]Draft
[23] http://www.w3.org/2001/tag/doc/metaDataInURI-31
DO: URIGP-40 was just a response to RF's assertion that parentheses
are bad in fragIDs, we can let that go
... but mIU-31 is more serious
NM: I see we have a draft from Stewart, but I can't tell why it
didn't go forward. . .
DO: I think there's lots of good stuff in there
NM: I asked because if there's broad agreement on what's there I'm
more sanguine about taking it on
<Zakim> ht, you wanted to mention persistent identifiers
<timbl> - HTML forms
NM: But if people aren't clear about where we are
HST: The InfSci community cares about this, it's one of the reasons
they keep inventing new URI schemes
<DanC> [24]issue metadataInURI-31
[24] http://www.w3.org/2001/tag/issues.html#metadataInURI-31
HST: But I don't have much time now to help move the issue forward,
don't even know what the draft says
<DanC> (my hazy recollection of stuart's draft is that it's too
long)
DC: I feel similarly, would pick it up if it were going to drop
altogether, but that wouldn't get it moving any time soon
NM: I can pick this up, but it will go on the queue behind other
things
... but again, no time soon
DC: Don't drop the issue, but drop all the actions against it
DO: I think this is _more_ important than schemeProtocols
VQ: We can't leave actions pending against people who have left
<noah> NM: Actually, I can also pick this up and put it ahead of
schemeProtocols
VQ: So let's withdraw the action wrt mIU-31 against his name
<noah> DO: Yes, ahead of schemeProtocols
<DanC> (I'd suggest dropping the action on SW similarly)
NM: I need guidance on relative priority soon
HST: See DC's suggestion
VQ: OK, will do that too
<noah> NM: I.e. I'm about to turn back to schemeProtocols as PLP
settles down (I hope). If the group prefers I do metadataInURI
first, then I'd rather know that before I swap SchemeProtocols back
in. Thanks.
<noah> VQ: Noah, settle it in email?
<noah> NM: fine, thanks.
VQ: so, next action on RF's list is putMediaType-38
<DanC> +1 continue
VQ: RF promises to deliver final draft in Mandelieu at the end of
February
... Next one is uriGP-40
<Norm> Get Roy to deliver his action!
<Norm> :)
VQ: RF does not expect he would get consensus for whatever he wrote
DC: Let's remove this from the issues list
... Covered elsewhere, I won't miss it
VQ: Others happy with that?
HST: Yes
(it was RESOLVED: uriGoodPractice-40 is to be removed from the list,
but we later recinded that decision)
VQ: Usual announcement?
TBL: We need to leave pointers for posterity
DO: I don't think the () issue exists elsewhere, will just get lost
DC: I'm happy for it be lost until someone cares enough to pick it
up
DO: History is that in the discussion of abstractComponentRefs-??
when XML Schema WG/WSDL WG said they would use XPointer, RF said
"(), bleuch", so we raised a new issue
... We closed aCR-37
DC: Hold on, aCR-37 is open
DO: We told the WSDL WG we were not going to push back further on
this point
... I think these two issues are orthogonal and should be treated as
such
<timbl> Where does it say why not to use () ?
<DanC> nowhere
<DanC> on the contrary; XPointer, a W3C Recommendation, says _to_
use ()s
DO: As long as we're happy that people can use ()s in fragids, we
don't need this issue
<timbl> Let us write soemwhere taht it is a bad idea becaus eyou
can't use qname-like shorthand for them.
DO: If that ever becomes a problem, then we should come back to this
TBL: So QNames were iintroduced to minimize the burden of long URIs,
but ()s in fragids render this solution unavailble
HST: I agree with DanC -- that issue, i.e. should any kind of
fragIDs other than barenames be avoided, because they bar the use of
QNames, is being discussed regularly by the TAG under other headings
VQ: DO, are you happy for this issue to be dropped
<timbl> Let's keep the issue.
DO: I think it was important to separate out from aCR-37, because
it's orthogonal
DC: I don't agree it's orthogonal, but I don't care about it, either
TBL: Move to 'someday' pile
<DanC> (I'm happy to leave 40 around until 37 is closed)
DO: OK, remove all actions against it, leave it rest until someone
feels we need to resurrect it
VQ: To conclude, no consensus to drop the issue, we need to leave
that for now
... For the sake of a clear history, we'll keep it open, but remove
all pending actions
RESOLUTION: Remove pending actions on RF wrt uriGP-40
[supersedes previous resolution wrt uriGP-40]
VQ: That's it for RF's outstanding actions
xmlFunctions-34
VQ: In Norm's absence, let's postpone this to a subsequent meeting
Principle of Least Power
<ht_> [25]New draft
[25] http://www.w3.org/2001/tag/doc/leastPower.html
<noah> [26]32 Jan draft
[26] http://www.w3.org/2001/tag/doc/leastPower-2006-01-23.html
<DanC> (tim, did you realize you wrote DesignIssues/Meaning , re
xmlFunctions-34 and self-describing web?)
<noah> [27]To do list and completed actions
[27] http://www.w3.org/2001/tag/doc/leastPower-2006-01-23.html#ToDo
NM: Appendix in the doc tracks my todo list
... Reordered the flow, cleaned up some details (SQL Turing
complete?), security concerns, what _is_ Turing completeness
... Comment that there are downsides -- too simple isn't good either
(Occam lives)
... RDF discussion untangled from HTML discussion
... Hope this is close to ready to ship
<Zakim> DanC, you wanted to ask why the principle is in a GPN box,
twice
DC: Why not a principle?
NM: I could see it go either way
... Willing to change it
... Clerical error, I suspect
TBL: It's definitely a principle
<noah> Good Practice: When publishing on the Web, choose the least
powerful or most easily analyzed language variant that's suitable
for the purpose.
NM: What about the added one about scalable
HST prefers GP for that
DC: That one _is_ phrased as a GP
... task is to get the first one into a non-imperative form
TBL: Right, rephrase it to make it look like a principle
<timbl> The more powerful the language the less reusable the
information.
DC: Other stuff is good
... Scope creep is a risk
NM: Yes, everybody wants to add a bit more
DC: Confirmed: the second box is to be left as a GP, but the first
box needs to be a Principle
<DanC> PROPOSED: to approve leastPower-2006-01-23 + change 1st GPN
to principle, contingent on thumbs up by @@(me? DanC?)
NM: I can make that small change in a day or two
DC: I'm happy to make a decision today
HST: Not ready to approve sight-unseen, sorry
NM: Target is consensus two weeks today, pending new sentence in
email/new draft by the end of the week
<scribe> ACTION: NM to circulate revised sentence for the Principle
by Friday 27 [recorded in
[28]http://www.w3.org/2006/01/24-tagmem-irc]
[28] http://www.w3.org/2006/01/24-tagmem-irc
<DanC> (The biggest risk is that nobody will look at the revision
right away, and then we'll forget in 2 weeks, and then noah will
forget to change the GPN to a principle again ;-)
VQ: Nearing the end of the call -- we will come back WSDL/RDF next
week
<noah> I think Tim's proposal of "The more powerful the language the
less reusable the information." seems right, or at least very close.
<noah> I'll start with that and noodle on it.
DC: Two weeks, because TBL is critical resource
Summary of Action Items
[NEW] ACTION: NM to circulate revised sentence for the Principle by
Friday 27 recorded in [29]http://www.w3.org/2006/01/24-tagmem-irc]
[NEW] ACTION: NM to convey this to the WSA WG [recorded in
[30]http://www.w3.org/2006/01/24-tagmem-irc]
[NEW] ACTION: VQ to prepare a summary in the next few days,
circulate to tag@w3.org for review, then go public depending on
feedback recorded in [31]http://www.w3.org/2006/01/24-tagmem-irc]
[29] http://www.w3.org/2006/01/24-tagmem-irc
[30] http://www.w3.org/2006/01/24-tagmem-irc
[31] http://www.w3.org/2006/01/24-tagmem-irc
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [32]scribe.perl version 1.127
([33]CVS log)
$Date: 2006/01/30 14:16:52 $
[32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[33] http://dev.w3.org/cvsweb/2002/scribe/
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Monday, 30 January 2006 14:19:53 UTC