- From: <noah_mendelsohn@us.ibm.com>
- Date: Mon, 10 Aug 2009 16:48:20 -0400
- To: www-tag@w3.org
- Cc: public-tag-announce@w3.org
A text-only copy of the minutes from the third day of the TAG's F2F
meeting in June, 2009 is attached.
Noah
[1] http://www.w3.org/2001/tag/2009/06/25-minutes.html
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
[1]W3C
[1] http://www.w3.org/
- DRAFT -
TAG f2f
25 Jun 2009
[2]Agenda
[2] http://www.w3.org/2001/tag/2009/06/23-agenda
See also: [3]IRC log
[3] http://www.w3.org/2009/06/25-tagmem-irc
Attendees
Present
Raman, Noah, Larry, Dan, Henry, Ashok, Jonathan, TimBL, John
Regrets
Chair
Noah
Scribe
Ashok
Contents
* [4]Topics
1. [5]Naming Schemes
2. [6]HTTP Semantics
3. [7]TAG f2f scheduling
4. [8]Tag priorities and future work
5. [9]Architecture for Web Applications
6. [10]HTML 5 review
* [11]Summary of Action Items
_________________________________________________________
Naming Schemes
<scribe> scribenick: Ashok
<scribe> scribe: Ashok
HT: Introduces document [12]Dirk and Nadia design a naming scheme -
or - Web naming schemes good practices
([13]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
[12] http://www.ltg.ed.ac.uk/~ht/justSayHTTP.html
[13] http://www.ltg.ed.ac.uk/~ht/justSayHTTP.html
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> [14]http://larry.masinter.net/9909-twist.pdf
[14] 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 [15]http://www.w3.org/ is correctly bound to an evolving
home page.
[15] http://www.w3.org/
<timbl> There is no reason why we could not make a design in which
domain names are permanent. I have proposed this
[16]http://www.w3.org/DesignIssues/PersistentDomains.html
[16] 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>
[17]http://www.adobe.com/devnet/xmp/pdfs/DynamicMediaXMPPartnerGuide
.pdf#page=19
[17]
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>
[18]http://lists.w3.org/Archives/Public/public-awwsw/2009Jun/0064.ht
ml
[18]
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> [19]http://esw.w3.org/topic/AwwswDboothsRules
[19] 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 [20]diagram
... boxes are types [classes]. Solid headed arrows say the
relationship holds between some instances of the 2 types.
[20] http://www.w3.org/2001/tag/awwsw/jar-diagram-7.pdf
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
[21]http://www.w3.org/2009/06/25-tagmem-irc]
[21] 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
[22]http://www.w3.org/2001/tag/2009/06/TagPriorities.txt)
[22] 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> [23]http://www.w3.org/2001/tag/group/track/actions/283
[23] 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> [24]http://www.w3.org/2001/tag/group/track/actions/282
[24] http://www.w3.org/2001/tag/group/track/actions/282
<noah> [25]http://www.w3.org/2001/tag/2009/06/TagPriorities.txt
[25] http://www.w3.org/2001/tag/2009/06/TagPriorities.txt
<noah> [26]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
[26] 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> [27]http://www.w3.org/2001/tag/group/track/actions/283
[27] http://www.w3.org/2001/tag/group/track/actions/283
<noah> [28]http://www.w3.org/2001/tag/2009/06/TagPriorities.txt
[28] 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> [29]http://www.w3.org/2001/tag/group/track/actions/278
[29] 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> [30]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
.
.
.
[30] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
Architecture for Web Applications
NM: so we have
[31]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html ... Jonathan
has the action to carry it forward...
[31] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
action-284?
<trackbot> ACTION-284 -- Jonathan Rees to flesh out the Web
Application ([32]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html)
outline with as many sentences as he can -- due 2009-07-01 -- OPEN
[32] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html)
<trackbot> [33]http://www.w3.org/2001/tag/group/track/actions/284
[33] 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> [34]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
[34] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
DanC: how about trying a pattern language wiki?
HT: what's that?
<timbl> Maybe [35]http://c2.com/cgi/wiki
[35] http://c2.com/cgi/wiki
<DanC_> yes, esp [36]http://c2.com/cgi/wiki?PatternLanguage
[36] http://c2.com/cgi/wiki?PatternLanguage
<timbl> [37]http://perldesignpatterns.com/?PerlDesignPatterns
[37] 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" --
[38]http://www.w3.org/2004/10/27-tag-charter.html
[38] 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>
[39]http://random.org/integers/?num=80&min=1&max=1099&col=8&base=10&
format=html&rnd=new
[39]
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
[40]http://www.w3.org/2009/06/25-tagmem-irc]
[40] 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>
[41]http://www.whatwg.org/specs/web-apps/current-work/html5-letter.p
df
[41]
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 [42]http://www.w3.org/2009/06/25-tagmem-irc]
[42] 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 [43]http://www.w3.org/TR/html5/
[43] http://www.w3.org/TR/html5/
<DanC> why not, timbl?
<masinter> that document has 979 pages
<timbl> Beause it is not as freshas
[44]http://dev.w3.org/html5/spec/Overview.html
[44] 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 [45]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
[46]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
[47]http://www.w3.org/2009/06/25-tagmem-irc]
[45] http://www.w3.org/2009/06/25-tagmem-irc
[46] http://www.w3.org/2009/06/25-tagmem-irc
[47] http://www.w3.org/2009/06/25-tagmem-irc
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [48]scribe.perl version 1.134
([49]CVS log)
$Date: 2009/07/21 22:17:44 $
[48] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[49] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 10 August 2009 20:46:42 UTC