See also: IRC log
NW: Agenda recently updated --
accepted as posted http://www.w3.org/2001/tag/2007/08/13-agenda.html
... Resolved that minutes of 16/7/07 are approved
DC: SW, have you created the "HTTP Redirections" issue?
SW: Wasn't aware we'd chosen a name, will go ahead ASAP with "HTTP Redirections"
<scribe> ACTION: SW to create new TAG issue called "HTTP Redirections" per minutes of 16/7/07 [recorded in http://www.w3.org/2007/08/13-tagmem-minutes.html#action02]
<trackbot-ng> Created ACTION-9 - Create new TAG issue called \"HTTP Redirections\" per minutes of 16/7/07 [on Stuart Williams - due 2007-08-20].
<scribe> ACTION: Stuart to put up straw poll to try to find a new slot for this meeting [recorded in http://www.w3.org/2007/08/13-tagmem-minutes.html#action01]
<trackbot-ng> Created ACTION-8 - Put up straw poll to try to find a new slot for this meeting [on Stuart Williams - due 2007-08-20].
RL withdraws his regrets
NM says he is at risk
We already have regrets from TBL
NW: Any suggestions?
<Stuart> http://lists.w3.org/Archives/Member/tag/2007Jul/0031.html (Member-only URI)
SW: I sent the above as a
starter
... URI-based extensibility
... Web 2.0
... HTTP URIs rule
TVR: Challenge is how to raise these, or any topics, in a way that works for the TP
DC: Molly Holzschlag has asked for observer status at the HTML WG meeting, which is fine with me, and has made some suggestions for a TP session (see http://www.molly.com/2007/08/11/dear-w3c-dear-wasp/)
NW: Who is WaSP (Web Standards Project) -- relation with WHAT WG?
HST: They've been around for a long time
DC: They have pushed for a more
aggressive attempt to support standards than W3C has pursued,
in that W3C has a policy of not making public criticisms of its
members if at all possible
... I also think we could talk about the relationship between
rel='nofollow' and <marquee> -- if the latter is bad, why
isn't the former?
NM: Wrt URI-based extensibility, is that where we talk about HTML 5 extensibility, or does that need a separate heading/slot/bullet?
TVR: Even if it is covered, the title doesn't communicate that
Various: The overall topic is a big one
NW: TP is a good place to talk about big topic
TVR: Start with the smaller (HTML5) topic, and then enlarge
SW: The topic emerged from our call discussion about follow-your-nose, we had trouble articulating exactly what we wanted, so it seemed a good topic
<Noah> Now that I think about it: the need for distributed HTML 5 extensibility is, as a requirement. Applying URI-based extensibility in particular is the Web-compatible way of achieving such extensibility.
NW: So, do we have consensus? Should we address HTML5 extensibiliyt
<Rhys> +1 to the broader topic
HST: I thought we had consensus on the broader topic
NW: I'm happy to go to the broad topic
NM: Once you agree on distributed extensibility as a requirement for HTML5, you still have to agree mechanism, i.e. URI-based or not
DC: How much time do we
have?
... I could imagine a whole conference on this topic
NM: I thought this was for the whole day
<Noah> Any interest in inviting Sam Ruby to discuss his views on HTML 5 extensibility?
NW: The message subject is "Any interest in a TAG-driven session during the 2007 W3C Tech Plenary Day?"
SW: Is this the subject that we have the most affinity for?
DC: 'We' isn't the point - I have a specific pointI want to get across
NM: Molly was particularly concerned about Adobe's AIR and application construction in general, which would I guess point also to Microsoft's Silverlight
DC: The TP programme committee has a list of 20 topics to talk about, see http://www.w3.org/2007/11/07-TechPlenAgenda.html (Member-only link)
<Noah> Speaking just for myself, I find some of the technical topics we're noodling on here to be more compelling than the rough list at 07-TechPlenAgenda.html
NW: Are we ready for the chair of the TAG to go back to Steve with an overview of what we've discussed, and see where it might fit in?
<scribe> ACTION: SW to discuss TAG slot at TP with Steve Bratt, informed by above discussion [recorded in http://www.w3.org/2007/08/13-tagmem-minutes.html#action03]
<trackbot-ng> Created ACTION-10 - Discuss TAG slot at TP with Steve Bratt, informed by above discussion [on Stuart Williams - due 2007-08-20].
NW: Same question about the AC -- anything to say?
HST: It's half-a-day, I think we should duck
DC: We don't seem to be doing REC-track work -- if anybody cared I guess we'd hear about it. . .
<Noah> I agree with Norm, we haven't forgotten rec track work. What we have not done is produce 3 month heartbeats so identified.
HST: At Extreme last week, I got a lot of good response when I pointed people to the http://www.w3.org/2001/tag/doc/alternatives-discovery.html finding -- we could just make it a REC
NW: I just don't think our recent work has been REC-like, we're still looking for that
<DanC> Alternatives finding is dated 1 November 2006 )
NM: I think a lot of our recent pubs can be seen as a heartbeat
<DanC> (our last WD was http://www.w3.org/TR/2006/WD-namespaceState-20060329/ )
NM: Most recent approved finding was Metadata finding, at beginning of the year
DC: We have to do a written
report which summarises what we've done
... If anyone objects, we'll here about it
<scribe> ACTION: SW to tell Steve Bratt that the TAG doesn't want a slot at the AC meeting [recorded in http://www.w3.org/2007/08/13-tagmem-minutes.html#action04]
<trackbot-ng> Created ACTION-11 - Tell Steve Bratt that the TAG doesn't want a slot at the AC meeting [on Stuart Williams - due 2007-08-20].
NW: Who has not read http://www.w3.org/2001/tag/2007/08/versionBlog.html : HST, DC, TVR
NM: It's not long, shall I walk through it?
NW: Go ahead then
NM: We've gotten some pushback from DO and Mark Baker
<DanC> (hmm... it's not clear that the quoted GPN is quoted, especially when the one that's not quoted looks the same)
[Scribe not trying to transcribe NM's walkthrough]
<DanC> [this bit about xml 1.1 is awfully relevant, and yet it's not in there? odd.]
<DanC> [perhaps the xml 1.1 versioning situation fits better in a separate item.]
<DanC> [the "ASCII doesn't have a version identifier" example that Noah often uses isn't in here. odd.]
HST: There's a shift between
"provide for marking version" and "when to mark version" in
your prose
... That seems to me to take us off track
NM: I think those are closely related -- if you would never want to mark the version, then the language shouldn't provide the mechanism for you to do so.
HST: My understanding of the existing BPN is that if you don't give people a way to mark versions, they will make one up, which will not be interoperable, so even if you don't know for sure what it will be used for, you should leave a place for it
NM: If you can't spec. what the version indicator means, you shouldn't have it in your spec.
<DanC> [I hear Noah defending his position but not convincing HT. I think the article is interesting as is, and I'd like to see it go out signed "Noah, a TAG member" and let other TAG members respond with other articles or comments.]
NM: You will just be storing up trouble for the future, c.f. XML's version attribute
HST: Brings us back to the metapoint as to what the status of TAG blog entries should be -- the settled will of the TAG as a group, or an opportunity for TAG members to discuss something using the blog medium?
NM: DO said something similar
SW: I think the value of a blog would be lost if it required consensus
TVR: I agree, we shouldn't turn TAG blog entries into mini-findings
NM: I think we should reserve the possibility that we do both, that is, we may sometimes want to publish something with consensus
NM: and that I can ask for telcon review on how to make the best posting I can, before I post it
<DanC> (sure, a little telcon preview is a good thing, from time to time)
<Stuart> +1 to DanC
<Norm> But not that I have to ask for it
<Rhys> +1 to the proposal on blog entries
NW: So it you remove "for the T A G" from the bottom, you can publish as and when you choose
NW: I'm also not sure that I'm unhappy with the existing WebArch GPN -- In NM's post, I'm not happy with the idea that the spec. author has to tell in advance whether there will ever be incompatible changes
TVR: Just to make sure that we're not just talking about version attributes alone as the way of indicating version
NM: We get to namespaces in the last section
TVR: What about DOCTYPE line as a version identifier, which is what the HTML WG are going back and forth about
SW: The questions raised by the
article are closely related to the terminology and analysis in
the Versioning finding we're working on
... I think Mark Baker's comments are along the same
lines
NM: I thought his comments (about header metadata) were strictly-speaking out of scope, because the BPN is about in-band identifiers, but metadata is out-of-band
<Noah> Actually, media type is in-band from the point of view of an HTTP response, but we're talking here about specifications for and instance of particular data formats. In general, I don't >think< it's likely that media-types play a big role in the in-the-file versioning formats. Right?
<DanC> (er... let's not leave posting mechanics in the someday pile, please.)
DC: Movable Type is weblog
support software, in some ways the first one
... Karl Dubost installed it for W3C and interface it with our
CVS system -- this is good, but does introduce a 15-minute
delay
DC: It supports categories, so if you categorise things they get syndicated, and can then be grabbed by a web page
<DanC> (yes, analagous to http://www.w3.org/html/ )
NM: What about formatting: monospace, display, etc?
DC: Karl is pretty good with CSS, I don't know what would happen if I added my own. . .
NW: Summarising -- Karl's setup can easily be expanded to allow us to log in, author new entries, categorise them as "TAG" and feed our blog page
SW: Different from B2 Evolution -based blogs?
DC: Yes -- advantage is it's baked not fried -- that is, the HTML is constructed only once, not on demand from a SQL DB
TVR: I don't mind what the content management is as long as it doesn't get in the way by producing opaque URIs
DC: I think we will got good URIs from Movable Type, including year, month and words from the title
<Norm> -> http//www.w3.org/blog/tag/
<DanC> (do I read this correctly? 4 objections to <http://www.w3.org/tag/blog> ?)
SW: That option was added late, so the no-entries may just be ones who never saw it
<Noah> Should we just do a prefer/live-with on the two surviving options right now on the phone?
<Norm> Yes, something like that.
<DanC> (I suspect http://www.w3.org/blog/tag/ is technically tied to b2evolution)
<Noah> +1
<Rhys> +1 to /tag/blog
<Norm> Proposed: http://www.w3.org/tag/blog/
SW: DC, can you organise the top-level 'tag' directory that we will need?
DC: Not without approval from TimBL. . .
DO: We can resolve on /tag/blog, pending approval
NM: I don't think we're in a great rush
<Norm> No objections.
NW: OK, lets try /tag/blog
Resolved: To locate the TAG blog at http://www.w3.org/tag/blog
<scribe> ACTION: DC to try to reach TBL to get approval [recorded in http://www.w3.org/2007/08/13-tagmem-minutes.html#action05]
<trackbot-ng> Created ACTION-12 - Try to reach TBL to get approval [on Dan Connolly - due 2007-08-20].
<Norm> Proposed title: TAG Lines
NW: Any objections to TAG Lines?
Resolved: The TAG blog will be called "TAG Lines", using the mechanisms established by Karl Dubost
<scribe> ACTION: DC to ask Karl Dubost if categories can be restricted to particular login lists [recorded in http://www.w3.org/2007/08/13-tagmem-minutes.html#action06]
<trackbot-ng> Created ACTION-13 - Ask Karl Dubost if categories can be restricted to particular login lists [on Dan Connolly - due 2007-08-20].
NM: We should try to use the description of whatever category we pick to make clear that it's for TAG members only
DC: I'd be happy if Yves Lafon wrote something about caching for him to use the category 'web architecture'
HST: Then we shouldn't use 'web architecture' for the TAG blog
NM: So two categories then, 'web architecture' and 'TAG Member', and I should use both for my post?
DC, HST: Yes
RL: New draft coming soon,
significantly changed, lots of new material
... available soon, then I'm mostly away until just before the
f2f, so you all can review
SW: I think we've had problems if we try to discuss things that aren't public. . .
RL: My plan was to put it in public space, but not announce it publicly
DC: Hmmm, I'd rather it were just out there
RL: But I won't be available to answer comments
NM: I've found that just saying that works pretty well
RL: OK, I'll go ahead and do that
NW: Background: W3C servers get hammered by tools which don't cache schema documents which they request very frequently
TVR: I don't see that this is a TAG issue
HST: I think it's a TAG issue, but not restricted to schema docs -- the Web provides for caching, if you anticipate large volumes of traffic from your site, or sites which use your software, to one or more stable resources, you should provide for caches
NM: More than that, I think our interest here follows from the advice to use only one URI for any given resource
DO: New issue or not, I think we
should take it on, because it follows from our advice on
avoiding multiple URIs
... We should follow through on the ramifications of our
recommendations
<DanC> (it's also true that people shy away from http URIs because they fear their server will melt down.)
<DanC> name brainstorm... httpCaching... hotSpot...
NW: I hear consensus we should take this up. New issue, or attached to an existing one? If new, then what name?
<Norm> ...representationCaching...managingHotURIs...
SW: schemas only?
TVR: No
<Norm> ...scalabilityOfPopularURIs
<Norm> ...uriScalability
<Stuart> ...frequentlyAccessedResources
HST: schemas, stylesheets (XSLT, CSS, ...)
TVR: Images
HST: Lists of e.g. language codes
<DanC> (caching proxies aren't enough in some cases... in some cases, products that ship with URIs hadcoded might as well ship with a representation hardcoded, and only phone home once every 6 months.)
<Norm> Right. Web frameworks running on end-user-machines don't have caching proxies necessarily
TVR: The architectural problem is in part that the publisher of a popular URI cannot in general ensure responsible caching by clients
NM: But we do expect providers of e.g. popular home pages to scale up their servers in keeping with demand
<DanC> ("economics aside" is not a tactic I want us to take. I want us to keep economics in mind.)
NM: So maybe the W3C is actually at fault here -- what's the division of responsiblity between provider and consumer?
<Noah> FWIW: I the reason I thought this discussion was useful was to >scope< the issue, which I think should go beyond caching
<Norm> ...scalabilityOfPopularResources
<Norm> scalabilityForPopularResources
<DanC> (I prefer URI to resource in this case, even though it's wrong. But oh well.)
<DanC> cachingBestPractices
<Norm> scalabilityOfURIAccess
<Noah> On economics, I agree, but when you say "ignoring economics for the moment" helps you to tease out which compromises you're making for mainly technical and which mainly economic. I claim that if W3C's funding were like Google's, they might not bother to lock out people who hit them at the rates we see.
<Noah> But yes, the fact that many providers can't afford to scale is a crucial (economic) piece of the puzzle.
<Norm> Proposed: The TAG accept a new issue, scalabilityOfURIAccess-58
<DanC> aye, and I don't care about the number
Resolved: the TAG accepts a new issue scalabilityOfURIAccess-58
NW: Someone willing to summarize this and send it to the list?
DC: NW, did Ted Guild's message cover the background?
NW: Not all. I'll take the action
<DanC> http://www.mnot.net/blog/2007/06/20/proxy_caching
NM: Do try to indicate that this isn't just about caching
NW: Will do
<scribe> ACTION: NW to announce the new scalabilityOfURIAccess-58 issue [recorded in http://www.w3.org/2007/08/13-tagmem-minutes.html#action07]
<trackbot-ng> Created ACTION-14 - Announce the new scalabilityOfURIAccess-58 issue [on Norman Walsh - due 2007-08-20].