Text-only version of TAG F2F minutes of 25 June 2009

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:43 UTC