W3C

TAG f2f

25 Jun 2009

Agenda

See also: IRC log

Attendees

Present
Raman, Noah, Larry, Dan, Henry, Ashok, Jonathan, TimBL, John
Regrets
Chair
Noah
Scribe
Ashok

Contents


Naming Schemes

<scribe> scribenick: Ashok

<scribe> scribe: Ashok

HT: Introduces document Dirk and Nadia design a naming scheme - or - Web naming schemes good practices (http://www.ltg.ed.ac.uk/~ht/justSayHTTP.html)
... I started over with Jonathan's help
... major strategic question: I could not find the right tone and right audience
... I started writing this as a request from a W3C AC rep who wanted a doc she could point to saying why we did not like XRIs
... There is a finding and a Journal paper mixed up in this document
... I now think I should stay with tone and audience of AWWW. Tone is light, recapping known facts with examples
... it's a doc for people who are thinking about designing names on the web. There may be a big appendix or a companion white paper

Noah: Pehaps a few minutes to read the paper first

LM: I have trouble with premise of the document
... people want to define new naming schemes, let them! What harm are we preventing?
... I don't see anything that says "Wow, that's terrible!"

TimBL: The damage is fragmentation ... 2 webs. Each with it's own naming scheme

Dan: There is a reputation that HTTP URIs don't really work. So, we say HTTP URIs solve these problems as well as anything else.

LM: If you were to change the title doc "How to use HTTP URis to identity long-lived resources robustly" that would capture your intention

<Zakim> noah, you wanted to talk about fragmentation

Noah: We should talk about potential damage from other naming schemes. Fragmentation
... If there is another scheme, software may change to handle both schemes. Or it may not.

<masinter> google is the naming scheme: put the name you're looking for into google

Noah: example of XRIs

LM: I gave a presentation in '99 -- problems URis don't solve
... some problems are not solvable

<masinter> http://larry.masinter.net/9909-twist.pdf

<Zakim> noah, you wanted to suggest we read the draft

HT: Some problems are about social contracts and no scheme can solve them
... Section 2 is almost unchanged

<noah> project which involves --> project that involves ??

<noah> Kill the paragraph beginning: Following the precedent of AWWW, we proceed ... ??

<DanC_lap> ed: the use of 'AWWW' grates on me

<DanC_lap> "At this point Dirk and Nadia both reply at once" was going to have a 3rd option, to use http, when last we discussed this, IIRC.

<DanC_lap> rather than "on the wrong track"

<timbl> "and the contingent nature of name registration" is fancy language for a non-academic document.

<noah> they all want names which are identifiable ===> what does it mean for a name to be identifiable?

<noah> ah, explained later.

<noah> I still don't like "URI in the scheme", because I think it uses the word scheme in a somewhat broader sense than RFC 3986

<DanC_lap> (does transparent subsume identifiable? maybe not as requirements)

<noah> transparent: as an aside, I wonder if a reference to the URI templates work would be helpful in this context

<timbl> "The IETF has rebound the http: scheme at least twice since its original binding." Well, hst, in a away, but in a way not: it is permanently bound t the evolving HTTP protocol, just as you have argued that http://www.w3.org/ is correctly bound to an evolving home page.

<timbl> There is no reason why we could not make a design in which domain names are permanent. I have proposed this http://www.w3.org/DesignIssues/PersistentDomains.html

<timbl> The TAG could instigate it

<noah> not quite sure the term "self-describing" is used in the same sense as in the SDW TAG finding. If different, then that's confusing.

<DanC_lap> "So, let's try a rewrite" is that an ed-note of sorts? I don't think I grok.

<noah> SDW Web finding really focuses on the chain of specifications, not retrievable metadata

<masinter> there are 40 URN namespaces registered, of which most are not in common use. I'm not sure why the TAG is spending time on something that isn't really a serious threat to web stability

<masinter> compared to many other more serious threats... i don't see the "split" really happening. People use HTTP schemes reguarly for identifying everything.

<masinter> an examination of other URI schemes and how they are or aren't used for identification might be interesting, as is an examination of the requirements

<masinter> when are GUID-based URI schemes appropriate?

<DanC_lap> "4.1. http: URIs are identifiable" could use an example

<masinter> what about protocol-specific schemes such as "mailto:" vs "smtp:"

<noah> Typo: The each identify a resource

<masinter> What about message-IDs in email messages and their mapping into HTTP space?

<masinter> What about form parameters in HTTP URIs and the problems with charset encodings?

<masinter> What about "file:" and its difficulties in mapping in an operating system independent way and the lack of a credible "authority" in most "file:" URIs?

<masinter> what about "widget:" vs "thismessage" for the Widget identifier?

<noah> http: -> "the http URI scheme (which we will hereafter abbreviate as http:). I've tripped several times over the fact that, per 3986 grammar, the colon is not part of the scheme name

<DanC_lap> Larry, how many people _know_ that there are 40 URN namespaces registered, most of which are not in common use? Are you sure it's not worth telling a few more people what you/we know?

<masinter> Well, how does this draft and approach do that?

<masinter> i'm not questioning that the TAG could do some useful work in the URI space, i'm just questioning this approach at the problem, considering my own experience in naming resources in XMP and the dfficulties I had

<DanC_lap> I'm not sure this draft does; we've tried several other approaches. There's no magic.

<timbl> I would like Dirk and Nadia to end up with a conversation in which the fragmentation issue is debated against their excitement about being about to work for a few year son engineering their own solution.

<masinter> I have a confession about having invented URI schemes for Dirk and Nadia

HT: In terms of addressing the underlying issue which is providing a resource for people thinking about what to do in this space, I think the most valuable aspect of this doc is the taxonomy in section 3

<DanC_lap> I think the XMP URIs didn't have the usability/dereferenceability requirement, did they, masinter ?

HT: if you look at the literature on persistence you find a range of wolly thinking. Getting clarity on what people want from names is hugely valuable.
... any gap in this terminology is very important to me
... this is not a knock-down-drag-out use HTTP. It tells the strengths of HTTP but does not analyze other schemes
... need to say that HTTP URIs work

Dan: They often say they don't have that requirement
... I added security at the end and I have a question on that

LM: I just invented 2 URIs schemes
... and I got my company to implement them
... so I'm feeling a bit attacked by this document
... anonymity was a requirement. Identity of art house that did post-producition markup should not be deriveable from the URI
... every video we identify has some metadata

<masinter> http://www.adobe.com/devnet/xmp/pdfs/DynamicMediaXMPPartnerGuide.pdf#page=19

<ht> So, 'global' is an implicit requirement which I should make explicit

Dan: The samentics of GUID ... [missed]

LM: There is unique place to put metadata. 2 identifiers: which doc and which instance
... there is a history chain

Dan: You have some way of looking this up?

HT: It's a cool scheme but does not share 2 or more requirements that are listed

Noah: You did not mention ability to email identifiers
... is that a requirement?

TBL: Isn't NM's example covered by 'useable'

<ht> I am in two minds about whether 'global' is usefully distinguishable from 'useable'

LM: The presumption is that stuff moves. And I want to retain identity
... There is an index
... Dirk and Nadia will not be happy if they have a URI and things have moved. Unreliable when things move. Better is use of index -- that requires more work

HT: Distinguish what the technology does and what the social contract does
... If you move then you have to implement a redirect

LM: Requirement to identify things in situations where things move and no opportunity to set up redirects and yet want to associate metadata after the fact
... retains identity after move.

Tim: 2 types to identifiers GUID identifier which has this property and another style which does not

<jar> maybe 'branded' instead of 'identifiable'

<jar> (branded to the naming scheme, not to the movie house)

HT: I have not been careful about that ...

Tim: This is very different from a GUID scheme.

LM: this is putting metadata in the identifier.

TimBL: People want that

<jar> analog with new uri scheme would be the uri scheme itself, not its user

LM: You want identity to be longer lived than the brand
... Some of these requirements are orthogonal to HTTP

HT: Yes... if you recognize these requirement then HTTP satisfies them. You may have other requirements

Tim: If we say these are just names but people have other needs

HT: Value of this doc is to identify requirements carefully. So people can say whether they apply to them or not
... someone has a requirement that names not be transparent

Noah: I tell people in IBM that people have requierments like these that they did not recognize
... we need to discuss pros/cons of implementations as well as requirements

<masinter> I think the document as written seems to talk about things as "requirements" when there are tradeoffs and there are properties of different URI schemes and situations

<masinter> anonymity vs. identifiability

<masinter> anonimity

Noah: we would do well to say the goal is to present a balanced view of the tradeoffs

<masinter> resolvability vs. permanence in the face of things moving outside of your control

<Zakim> ht, you wanted to answer larry: identifiable; global

<Zakim> jar, you wanted to ask lm so how did adobe think the requirements were going to be met? and to wonder whether the requirements can be partitioned into two sets: the ones that enable the argument, and other ones that can *also* be met (deconstruct 'whose requirements for what')

JR: Would be excellent if we could get the requirements in good shape

<masinter> I'm willing to serve as the prototypical "Dirk"

JR: please examine requirements carefully and say what applies and what does not

<masinter> I take responsibility for the "requirements", don't blame adobe

<masinter> i'd rather see "How to use HTTP URIs and still meet some requirements that you didn't think you could meet with HTTP URIs"

JR: Requirements serve 2 purposes: make people aware of what requirements are and to weed [?] people and then say these are what HTTP provides

<Zakim> DanC_lap, you wanted to contrast the guuid pattern with the pattern of an administrative hierarchy

JR: perhaps sort requirements into 2 groups

<masinter> administrative and organizational heirarchy *must* be opaque

Dan: Pattern or admin hierarchy gets lost ... different from GUID

<jar> 2 kinds of requirements. 1. let people figure out whether the advice is going to apply to them (whether they can ignore it), 2. additional requirements that *can* be met in systems of the sort that are recommended.

<masinter> strong customer requirement for not making internal organization or work processes visible or stripping such information while not losing identity

LM: uncomfortable calling desired properties as requirements

JR and Dan agree on 2 piles of requirements

HT: This is about Dirk and Nadia's requirements

LM: I know people in similar situations who have different requirements

Tim: Can you supply alternative text?

LM: If it's a requirement it's a MUST. If it's a should it is not a requirement

Noah: Applications may have different requirements

<ht> I'm happy to talk about goals/desiderata/etc., but I'm familiar with the notion of "requirements capture" which doesn't imply MUST

<masinter> Well, i've gotten some feedback to that effect, and I have some sympathy with Henry's terminology, i'm not sure about whether everyone in Dirk and Nadia's situation have those same requirements

<Zakim> ht, you wanted to ask about 'global' vs. 'useable'

<masinter> because the 'requirements' may be in conflict

HT: I would like comments on ....
... I don't use the word persistence becuase use it in different ways

<masinter> if people use the word 'persistence' incorrectly, then the finding should say why the meaning is imprecise

HT: wanting resource stability 'Cool URIs don't change'
... that's what people also want from 'persistence'. Sometimes they want something stronger which I call representation stability ... I want the same bits

<masinter> the main thing people are confused about is the difference between 'having a name' and 'having a guarantee of a future service of name lookup', and people being tied to name resolution services without being aware of it

HT: people say they want this but they often do not

HT ... time varying resources

<masinter> documentid and instanceid separate intent vs. representation

<masinter> think identity should be 'weak etag' or 'etag' identity

JR: It was an explicit requirement for LSID that if you get the data you get exactly the same data ... this is to support replicability of experiments

HT: This is a real representation stability requirement
... example is public key ... need same bits

<masinter> think this is missing the economics aspect

<jar> maybe 'purpose stability'

<masinter> noah talking about 'data:' URI scheme

Noah: Suggesting that a case to think about pros and cons of a scheme called data vs. http

HT: What I intend to do is finish the rewrite so that if people stop after section 4 they will have got the jist of the argument
... would like to enlist Jonathan's help again
... on requirements capture
... by the end of July I will be able to provide a completed draft thru section 4

Noah: Are ready to agree to this?

LM: I'm uncomfotable with direction of this. So I'm reluctant to agree

HT: That's fair warning

Noah: Larry, are you saying that I wish this went away or are you saying this area of clarification is useful but don't like direction.

LM: I'll talk to Henry on the break

BREAK for 15 minutes

HTTP Semantics

JR: Presents

<jar> http://lists.w3.org/Archives/Public/public-awwsw/2009Jun/0064.html

JR: weekly telcons for ad hoc task force
... putting relationship between HTTP and RDF on a more rigorous footing
... Explains linked-data nose-following from RDF or RDF terms to more RDF

<masinter> thinks we need something that abstracts away from "HTTP as spoken" and proposes an abstraction which can be mapped to HTTP for better orthogonality

Tim: Asks about David Booth's rules

<jar> http://esw.w3.org/topic/AwwswDboothsRules

JR: These are nose-following rules
... I want to compare these to my version
... mine are written in bash [not N3]

<masinter> architectural principle of orthogonality: HTML shouldn't depend on or rely on HTTP. I think same is true for Semantic web. Definition of semantics and meaning shouldn't be tied to "http:". However, would like some abstraction. "GET with success" vs. "GET with redirection" is fine. Both "http" and "ftp" implement "GET with success", but in HTTP it is a 200 response

<masinter> "ftp" doesn't implement "redirect", but HTTP does, and uses 301 code

<masinter> inserting a level of abstraction helps identify what part of HTTP is being used

JR: for all redirects resource resides at different URI

<masinter> What does semantic web *need*? Rather than trying to describe HTTP, describe what Semweb needs and how HTTP can deliver it

HT: Asks about 307

Tim: This is not true of 302

JR: It's saying what you believe is true
... e.g. the correspondence held at these times

JR: I have sent in some gentle suggestions
... Explains diagram
... boxes are types [classes]. Solid headed arrows say the relationship holds between some instances of the 2 types.

LM: I have some general comments

Yellow boxes are classes and relationships used in the curation

scribe: white boxes ... discussion

<raman> calling zakim

JR: I would call them 2616 resources. 'Resource' as defined in 2616

<raman> ethere by myself now a single unbalanced tag ...

LM: Need abstraction layer ...

JR: That's what this is.

LM: Is this descriptive or prescriptive?

<raman> I'll wait another minute then give up, hang up

Raman, we are dialing in

LM: Problem is some edges are not captured.

JR: I'm capturing edges used in linked-data
... I can put something in front explaining the space

LM: Idealized abstraction of HTTP useful for ... disclaimer of this sort

Dan: I'm not seeing this that way. He's giving labels to concepts in the spec

<masinter> use case: content-type sniffing

JR: constraints within which a resource operates

LM: Content negotiation

JR: and time-varying resources

LM: Content sniffing

<Zakim> masinter, you wanted to wonder if the intent is to be descriptive or prospective

LM: Sniffing is there for a reason... they did not want to do it but found they must
... if we could capture the reason that would be useful
... TAG has been accused of letting theory get in the way of practice

Tim: We can model a clean or dirty system
... we can model the game theoretical basis basis
... you have to do the game theory of both parties .... browser manufacturers

LM: We should at least identify agents to figure out who is being gamed by whom

JR: My approach is to create subclasses
... then [ideally] we can prove some theorems about the consequences of that

LM: Another layer between msg and media
... , would give you a place to see where content sniffing goes on and who is doing it
... if model is helpful in thinking about this then that validates it
... Char-set defaults which is a kind of content sniffing and mapping this to less functional protocols

JR: Metadata could give you the correspondences

LM: Should tie abstract TAG work to what people are concerned with

Noah: That will keep this work pertinent
... but people have issues that this will help with
... about content neg there is squishiness about what a resource really is

JR: We could talk about generic resources or httpRange-14
... I did a review of issue-57. I think it would be good to drive this to closure

LM: How would Raman's doc fit into this model?
... Can this model help use describe where Web Arch is going, where the ambiguities are ...

<masinter> can it help us understand web applications?

<masinter> when the message contains 5 lines of HTML: 4 imports of javascript and one 'all' that then draws things on the screen

HT: A large gap between the representation and the resource .... Javascript stretches intution about resources

Raman: Agrees ... we are at the point where we need one more concept

HT: presentation

Raman: Generator
... content is generated

LM: I have been using 'behaviour'

Tim: I like patterns
... discusses different patterns .... some simple, some very complex
... patterns used to a greater or lesser extent

Noah: I hope we can tell that same story informed by this analysis to fill in table of contents

HT: Picture can be used with different patterns

JR: Wrapping up ... glad to hear this ... this is very abstract
... what Tim calls patterns, Alan calls classes
... would be good to explain this

Noah: Where are we going with this ?
... next session is about TAG priorities

LM: Getting examples of how this will describes controversies and problems would be very good.

BREAK UNTIL 1:30 PM

TAG f2f scheduling

<DanC_lap> scribeNick: DanC_lap

PROPOSED: to meet 8-10 Dec 2009 in Cambridge, contingent on consulting with John and Raman

<noah> Note that we agreed that chair will check with Raman and John on this.

<noah> ACTION: Noah to check with John and Raman on agreed Dec. 8-10 2009 MIT F2F [recorded in http://www.w3.org/2009/06/25-tagmem-irc]

<trackbot> Created ACTION-286 - Check with John and Raman on agreed Dec. 8-10 2009 MIT F2F [on Noah Mendelsohn - due 2009-07-02].

RESOLUTION: to meet 8-10 Dec 2009 in Cambridge, contingent on consulting with John and Raman

<raman> calling zakim

<noah> Strong preferences for avoiding following week

TVR: not sure I can make the 8-10 Dec meeting in Cambridge, but no objection to it

<scribe> scribenick: DanC_lap

Tag priorities and future work

<ht> tv, we are resuming -- you there?

Note NM takes notes offline... (Checked in at http://www.w3.org/2001/tag/2009/06/TagPriorities.txt)

NM's notes say, roughly: 1) HTML 5 2) Web Applications Architecture 3) Other things to do with metadata

NM: so where does URNsAndRegistries-50 fit?

[missed answer]

AM: and geolocation? where does that fit? webapps?

LM: yes, I think so, at a high level

NM: OK, so revise this to be our Primary Focus split -- there's room for wind-down of existing work, and high-priority interrupts as necessary

<jar> Where it fits: urnsandregistries is a 'secondary' focus

NM: I think we have actions on metadata, right?

[right]

action-283?

<trackbot> ACTION-283 -- Larry Masinter to update document on version identifiers w.r.t. Cambridge June discussion -- due 2009-07-24 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/283

close ACTION-270

<trackbot> ACTION-270 Provide additional material for review at F2F for Issue 41 closed

close action-272

<trackbot> ACTION-272 Report back to the TAG on outcome of collaboration with LM on Versioning closed

action-282?

<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on metadata architecture. -- due 2009-08-31 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/282

<noah> http://www.w3.org/2001/tag/2009/06/TagPriorities.txt

<noah> http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

action-283?

<trackbot> ACTION-283 -- Larry Masinter to update document on version identifiers w.r.t. Cambridge June discussion -- due 2009-07-24 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/283

<noah> http://www.w3.org/2001/tag/2009/06/TagPriorities.txt

action-278?

<trackbot> ACTION-278 -- Jonathan Rees to draft changes to 2.7 of Metadata in URIs to cover the "Google Calendar" case -- due 2009-07-07 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/278

NM: this looks good... the actions we assigned over the last few days align well with these priorities

<noah> http://www.w3.org/2001/tag/2009/06/webAppsTOC.html


.
.
.

Architecture for Web Applications

NM: so we have http://www.w3.org/2001/tag/2009/06/webAppsTOC.html ... Jonathan has the action to carry it forward...

action-284?

<trackbot> ACTION-284 -- Jonathan Rees to flesh out the Web Application (http://www.w3.org/2001/tag/2009/06/webAppsTOC.html) outline with as many sentences as he can -- due 2009-07-01 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/284

jar, fyi, COMA?T is comet

jar: I started making larger clumps...

NM: this might be as much a taxonomy of issues more than a TOC

jar: yes... something about the TOC structure didn't suit me

<noah> http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

DanC: how about trying a pattern language wiki?

HT: what's that?

<timbl> Maybe http://c2.com/cgi/wiki

<DanC_> yes, esp http://c2.com/cgi/wiki?PatternLanguage

<timbl> http://perldesignpatterns.com/?PerlDesignPatterns

TimBL: Christopher Alexander wrote a book on architecture patterns...

NM: and there's a software Design Patterns book

DanC: yes, something like that... a collection of problem/solution patterns

JAR: I'm happy with the OWL WG wiki

[discussion of mechanics]

[discussion of policies]

<jar> actually that's *very* happy. they did a great job. lots of cool add-on technology e.g. they generate WDs directly from the wiki.

TBL: I'm interested in a pattern wiki for its own sake... remember that for things like web applications we're not the experts

JAR: I think a TAG wiki is likely useful for patterns and other things... use cases... anything we can get the community to contribute helps us multiply our few resources

AM: I'm a bit concerned that not everything fits so well into patterns

<jar> owl wiki is only writable by WG members

boring

<jar> right. not recommending that.

<jar> there's access control

<jar> groups

<masinter> I think the role of the TAG is different from that of a working group

<masinter> I don't think the TAG's role or responsibility is to represent the "consensus" of the community, in the same way that a W3C working group *does* have that responsibility

wow.

"W3C has created the TAG to document and build consensus around principles of Web architecture" -- http://www.w3.org/2004/10/27-tag-charter.html

<masinter> yes, document and build, not represent

LMM: the TAG's responsibility to compromise to get consensus isn't as great as a WG with an implementation community

<masinter> well, not exactly

<masinter> the TAG is responsible for leadership, which may not require compromise

NM: supposing we thought it was a good idea, Dan, are you willing to maintain it?

DanC: yes

timBL: couldn't we just use the esw wiki?
... Noah, do you ever use the esw wiki?

NM: NM: I use it and it has some serious shortcomings. It's slow and it uses a non-standard markup language, which is a big nuisance when you are trying to copy/paste HTML or other standard formats.

<masinter> I don't think anyone has the 'responsibility' to 'compromise'... Working groups have a responsibility to reach consensus, and that may require compromise. The TAG has a responsibility for leadership, and compromise is not as useful a tactic for leadership

<masinter> leadership means getting people to follow. it means making proposals that make sense to the community, and dealing with input. this is getting pretty far off the topic of wiki though

NM: hmm... discussion of the wiki doesn't seem to come to any particular conclusion


.
.

NM: so on architecture for web applications... are we agreed that explaining the community how to use web architecture to build web applications as well as publish documents is a priority?

LMM: well, the community knows how to build them...
... we're trying to develop architectural guidelines


.
.

<masinter> we're going to develop what we believe are useful architectural guidelines

HTML 5 review

[discussion of how to organize review of HTML 5 ]

LMM: I'm willing to do a guided tour of a couple specific sections

poll shows 3~4 think assigning sections to TAG members is a good idea. [missed other numbers; help?]

LMM: let's look at sections together
... In particular, I'd like to follow up on criticisms that it's too long, algorithmic, browser-specifc, [and a few others]

<jar> http://random.org/integers/?num=80&min=1&max=1099&col=8&base=10&format=html&rnd=new

<noah> ACTION: Noah to schedule telcon time for Larry to walk us through a few short sections of HTML 5 document [recorded in http://www.w3.org/2009/06/25-tagmem-irc]

<trackbot> Created ACTION-287 - Schedule telcon time for Larry to walk us through a few short sections of HTML 5 document [on Noah Mendelsohn - due 2009-07-02].

<DanC> I bid for sections 1 and 2

AM showed interest in offline apps

NM: we could [...] or let people express interest in email

<masinter> (/ 1000 9) = 111 pages each

<masinter> http://www.whatwg.org/specs/web-apps/current-work/html5-letter.pdf

<noah> ACTION: Henry to arrange "divying" of HTML 5 into sections such that each part of spec is read by at least one TAG member [recorded in http://www.w3.org/2009/06/25-tagmem-irc]

<trackbot> Created ACTION-288 - Arrange "divying" of HTML 5 into sections such that each part of spec is read by at least one TAG member [on Henry S. Thompson - due 2009-07-02].

<timbl> Presumably not http://www.w3.org/TR/html5/

<DanC> why not, timbl?

<masinter> that document has 979 pages

<timbl> Beause it is not as freshas http://dev.w3.org/html5/spec/Overview.html

<DanC> I think reviewing /TR/html5/ is good in that it motivates the HTML WG to publish more often

<timbl> It means our reviews would be less relevant

<DanC> doubt it

<DanC> maybe in some cases

<masinter> ask you that when you're reading to see if there's some way of articulating issues that are general but backed up by specifics

<timbl> I have Version 2.2.1 (4132) and it seems to work

ADJOURN.

Summary of Action Items

[NEW] ACTION: Henry to arrange "divying" of HTML 5 into sections such that each part of spec is read by at least one TAG member [recorded in http://www.w3.org/2009/06/25-tagmem-irc]
[NEW] ACTION: Noah to check with John and Raman on agreed Dec. 8-10 2009 MIT F2F [recorded in http://www.w3.org/2009/06/25-tagmem-irc]
[NEW] ACTION: Noah to schedule telcon time for Larry to walk us through a few short sections of HTML 5 document [recorded in http://www.w3.org/2009/06/25-tagmem-irc]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.134 (CVS log)
$Date: 2010/01/06 22:22:30 $