See also: IRC log
<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
<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
... 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
... 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
<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
... 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
... 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
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
... 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
JR: weekly telcons for ad hoc
... 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
JR: These are nose-following
... 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
... e.g. the correspondence held at these times
JR: I have sent in some gentle
... 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
... 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
... 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
... then [ideally] we can prove some theorems about the consequences of that
LM: Another layer between msg and
... , 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
... 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?
Raman: Agrees ... we are at the point where we need one more concept
... 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
... 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
<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
<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?
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?
<trackbot> ACTION-283 -- Larry Masinter to update document on version identifiers w.r.t. Cambridge June discussion -- due 2009-07-24 -- OPEN
<trackbot> ACTION-270 Provide additional material for review at F2F for Issue 41 closed
<trackbot> ACTION-272 Report back to the TAG on outcome of collaboration with LM on Versioning closed
<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on metadata architecture. -- due 2009-08-31 -- OPEN
<trackbot> ACTION-283 -- Larry Masinter to update document on version identifiers w.r.t. Cambridge June discussion -- due 2009-07-24 -- OPEN
<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
NM: this looks good... the actions we assigned over the last few days align well with these priorities
NM: so we have http://www.w3.org/2001/tag/2009/06/webAppsTOC.html ... Jonathan has the action to carry it forward...
<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
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
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: 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
<jar> right. not recommending that.
<jar> there's access control
<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
"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?
timBL: couldn't we just use the
... 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
[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
... In particular, I'd like to follow up on criticisms that it's too long, algorithmic, browser-specifc, [and a few others]
<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
<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