See also: IRC log
<DanC> Scribe: Dan Connolly
<DanC> ScribeNick: DanC
<DanC_> minutes 6 Sep
RESOLUTION: to approve minutes 6 Sep (2007/09/06 18:55:56)
SKW: one recent change to agenda; any other comments on the agena? We'll juggle a few things until Dave gets here...
PROPOSED: to meet again 27 Sep, Rhys to scribe
<ht> Regrets for 2007-09-27
Rhys: regrets 27 Sep [?]
RESOLUTION: to meet 27 Sep (scribe to be confirmed)
http://www.w3.org/2001/tag/2007/09/17-agenda Revision: 1.14 $ of $Date: 2007/09/11 09:54:43
SKW: Monday part of the meeting will stop at 5pm sharp if we're to take up the offer regarding a social event
HT notes weather merits warm clothing
<ht> For wind and weather forecasts, I recommend http://www.xcweather.co.uk/
<ht> There are weather stations for both Southampton and St. Catherine's Point
SKW: monday morning scribe?
HT: OK, I'll scribe Monday 17 Sep AM
DO: what time should I call in?
SKW: we plan to pick up
XMLversioning at 3:30pm UK time Monday
... same time window on Tues harder to predict, but agenda
calls for Tag Soup with TVR
<scribe> ACTION: Henry to revise URNsAndRegistries-50 finding in response to F2F discussion (ACTION-33) [CONTINUES] [recorded in http://www.w3.org/2007/09/13-tagmem-minutes.html#action01]
HT: my work on that got
preempted; sorry.
... yes, I saw Chime's comments.
... the http://esw.w3.org/topic/HttpUrisAreExpensive
was news to me; thanks
<DanC_> update "Authoritative Metadata"/ contentTypeOverride-24 based on HTML 5 spec?
DC: our position on contentTypeOverride-24 is: if it says text/plain, it's text/plain. Recent HTML 5 drafts say: if you're looking for an image, treat what comes back as an image, even if the MIME type says text/plain (or something pretty close to that)
<scribe> Scribe: Henry Thompson
<ht> ScribeNick: HT
NM: By "ask for an image" do you mean in the accept header?
DC: No, rather where the GET
comes from, i.e. the markup around the link
... I can't remember whether the HTML 5 spec says anything
about accept header
... I then thought about the overlap with HTTP
... and drafted an internet draft containing the sniffing
rules
... which was enough to get Roy Fielding to join the HTML
WG
... and some substantive discussion is now happening
... Ian Hickson says that having spent two years trying to do
the right thing, and losing
... He believes that any browser that doesn't sniff will lose
market share
... Fielding disagrees
... Hickson has in the past suggested the TAG would have more
credibility if they reopened the finding and added orange
cones, that is, "in practice" exceptions
<Zakim> Noah_Bangalore, you wanted to noodle a bit on accept headers vs. <img> tags
SW: I've always understood that the mime type as delivered is a statement of server intent, and that doesn't _entirely_ determine what client use must be
NM: it was asserted that the
semantics HTML 5 wants is something like "if the link was from
an <img> tag, then make different assumptions about
whether the returned representation is an image, regardless of
Content-Type".
... What bothers me about that is that not only is that
different from HTTP as specified today, you can't even specify
it in terms of information that's visible at the HTTP
level.
SW: Should we actually open this up?
<timbl_> I wouldlike to push back on the HTML WG
TVR: I'm not sure this is a good idea, on the grounds that we've already opened up the HTML issue, and we don't yet know what the result will be
<Zakim> DanC, you wanted to concur with TVR about the risk here
TVR: Until we know that the HTML WG will succeed, I'm concerned about putting even more of WebArch at risk
<timbl_> Who at microsoft is the person who has to make that decision?
<Rhys> I agree with Raman
DC: This is an issue which makes me worry about the viabililty of the HTML WG -- Ian Hickson's position is that we can't do anything that the major browsers won't come on board with. Roy Fielding's view is that that means abdicating responsiblity, and just standardise other folks bugs
DO: I agree that this is not in
the whole community's interest
... We had a less than completely successful attempt to do
better in the Web Services area, I don't think we should roll
over here as well
TBL: It's true that if we can't
get the big vendors to change their minds, we're in a mess. I
think the right answer is for the TAG to convince them to try
to make their browser help users do better
... I'm prepared to put some efforts into make this
happen
... For example, browsers should warn users when show
cleaned-up source on Show Source or when they have to
sniff
... Important to get this right _now_ -- this morning I was in
a meeting talking about video, and for a number of practical
reasons, content negotiation between the two major approaches
is going to be _very_ important
... and this is going to happen again and again, so we _should_
take up the challenge and try to persuade Firefox and IE and so
on
<Zakim> DanC, you wanted to report a bit of hope for a mozilla build with an option to make bogus mime types visible to the user, and meanwhile, a fairly serious proposal to reduce the
TVR: Sniffing is a slippery slope to disaster
DC: HTTP WG is thinking about
restarting at IETF
... fixing bugs, issues list, no WG yet but close
... Larry Masinter has filed an issue to deprecate content
negotiation
<DanC> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i81
DC: Julian Reshke said he'd like
a configuration option which said "show me the true mime
type"
... That seemed like a hopeful sign
<timbl_> ... application/xml;dammit
DC: There has also been discussion [where?] of replacing or down-grading or ??? the Content-Type: header, e.g. application/xmlDamnIt
<timbl_> I don't see at all how that will solve the problem that ISPs don't allow folks to control the MIME heders
SW: So reopening means strengthening our arguments, or considering changing our position?
<Noah_Bangalore> +1 to reopen
DC: Could go either way
<Noah_Bangalore> or at least a strong concur
<DanC> DC, Tim, Dorchard, Noah...
SW: In favour of reopening: 4
<Rhys> Rhys doesn't have a strong view
SW: Abstain: HST, SW, RL
... Opposed: TVR
<timbl_> +1
TBL: Do we have to reopen the issue to discuss it?
TVR: I'd like to discuss it, but not change it
<Zakim> ht, you wanted to say enforcement
<DanC> (if we just want to re-assert our position, I don't think we need to re-open it.)
<Noah_Bangalore> I'm discouraged. For years we've asked ourselves whether the time is right to tell the story of the new parts of the web, like SemWeb, in an AWWW vol 2. Now it feels like we're deciding how much of V1 to withdraw. Sigh.
HT: I think it's always in order to discuss how to best promote TAG findings
DC: Not opening it says we're not listening
<Noah_Bangalore> Not that I'm against openning the issue, just discouraged that we need to.
TVR: Opening it says we were wrong
<Noah_Bangalore> I also don't think that openning an issue signals a change. It signals a careful recheck, I think.
DO: I guess opening it is
sensible because it gives us a clean way to discuss, have
actions, etc.
... There's a precedent in what we did with xxx-7
<Noah_Bangalore> I do have to go now. See you in Southampton. Good night!
DO: So if we reopen and say "We're doing this because there's new information, and we want to track that and interact appropriately"
<DanC> +1 re-open (I think the economics of the issue merits re-opening it)
SW: Asking again -- should the TAG reopen the issue
TVR: What does opening it mean?
HST: That it stays open until we close it or abandon it
<timbl_> TBL: yes
SW: In favour: DC, DO, TBL
Abstain: HST, TVR, RL
DO: If we're not going to open this, we shouldn't talk about it
HST: What about opening a new issue on "How do we deal with the fact that the HTML WG is heading down a road that is incompatible with our finding on respectMediaType-???
TVR: I like that
DC: I could live with it, but I think it's odd
DO: Same here -- it seems like a heavy burden on our process
SW: Proposal to reopen fails -- only three in favour; majority of the TAG is 5
<DanC> ScribeNick: DanC
<ht> HST observes that there _was_ a majority in favour of talking about this matter. . .
SKW: proposal to re-open issue 24 didn't carry; other proposals are welcome. on to other items...
DO: Tech Plenary program
committee accepted one of our proposals, "The Importance URI
based Extensibility", aka distributed extensibility... 45
min...
... panel... with Q&A... <= 5 ppl... maybe 4...
... on the panel should be advocates of short strings as used
in microformats, somebody from HTML 5, etc.
... not sure if my role is just recruiting panelists, or MC, or
participant, or what...
<Rhys> I think it's fine for the MC also to be a participant in the panel.
TVR: goal of the panel? this is clearly a long-running discussion, but I'd like to set clear goals for this panel.
DO: re-inforce our message in support of decentralized language evolution
DanC: goal is at least getting more of the community up to speed, if not achieving a whole lot of novel technical progress on the panel itself
TVR: ok, outreach makes sense
SKW makes suggestion to mitigate the risk that presentations would use all the time
<Noah_Bangalore> FYI, I made some limited progress on the plane on the way over in reading both the terminology and strategies parts of Dave's versioning drafts. Whether I'll be able to wrap them in an email before the F2F is not clear, but I'll certainly try.
<scribe> ACTION: Dan Connolly to Review definitions of partial understanding, backward compatible, and forward compatible ACTION-4 [DONE] [recorded in http://www.w3.org/2007/09/13-tagmem-minutes.html#action02]
DanC: my review (Fri, 24 Aug 2007
16:57:37 -0500) said "I don't find this appealing; looks like
an open research problem". DO said "let's not formalize it that
deeply" which seems ok, perhaps, to me and Noah... as long as
it doesn't come up in the practical examples in the scenarios
part
... Marc de Graauw is working on a formalism; I found it
somewhat interesting as an academic exercise, but much moreso
now that he's pointed out that it's grounded in a real-world
scenario: HL7
<ht> ScribeNick: ht
DO: I've tried to add
definitions, based on information, but that did not find
favor
... Since I can't take it any further, I suggested dropping
it
... I'm also interested in Mark DeGraaw's work, since there's a
clear indication there of the value that success here would
provide
SW: HST, any input?
HST: I know of no solutions from the Computational Linguistics side
<DanC> ACTION: Dan Connolly to ask Mimasa and Mark Birbeck about feasability of using substitution groups in XHTML modularization, cc public-xml-versioning ACTION-27 [DONE] [recorded in http://www.w3.org/2007/09/13-tagmem-minutes.html#action03]
DC: I asked, I didn't get a
satisfactory answer
... Subst Groups are designed for distributed extensibility
<scribe> scribenick: danc
HT: I'm up to speed here... I read the modularization [of XHTML] spec and wrote up my thoughts...
(which see ACTION-15 )
<ht> http://www.w3.org/2001/tag/2007/09/xhtml-modularisation-thoughts.html
HT: indeed, substitution groups
are a great mechanism for distributed extensibility; I explain
how...
... a couple problems, 1 minor and 1 major...
... putting things in multiple substitution groups isn't
allowed in XSD-the-REC; it is in XSD-work-in-progress...
<timbl_> "clean subsetting"?
HT: but they [XHTML] have another
goal, that substitution groups don't do: "clean
subsetting"
... substitution groups are bottom-up, which is why they're
great for decentralized extensiblitiy...
... but XHTML modularization is also top-down; I dunno how to
do that with substitution groups
... I hope somebody finds a work-around
DC: this "clean subsetting" ... not sure I understand the motivation...
HT: you need it to build XHTML 1.1 out of modules
<DanC_> [I'm not able to grok that right away]
DO: this is an interesting point
on the design of XSD 1.1
... seems like XHTML is an important use case for XSD
<DanC_> [my understanding is that XHTML is _not_ widely regarded as an important use case for XSD]
HT: I'd be more interested in addressing that requirement in XSD 1.1 if I could see a clear design.
<scribe> ACTION: Henry S. Thompson to Review XHTML Modularization ACTION-15 [DONE] [recorded in http://www.w3.org/2007/09/13-tagmem-minutes.html#action04]
DC: DO, seen my msg about SMIL?
<DanC_> Subject: lots of SMIL namespaces, revisited [XMLVersioning-41 / ISSUE-41]
<DanC_> Date: Fri, 31 Aug 2007 12:52:24 -0500
DO: yes; saw that; been working on something related...
<scribe> ACTION: Stuart Williams to Look at the difference between QNAME in XML and SPARQL ACTION-34 [DONE] [recorded in http://www.w3.org/2007/09/13-tagmem-minutes.html#action05]
SKW: SPARQL uses "abbrevited names" which are similar to QNames, but not quite the same. [summarizing http://lists.w3.org/Archives/Public/www-tag/2007Sep/0036 ]
DanC: recent RDFa designs seem to not use CURIEs in the href attribute, but only in new attributes
some investigation into current status of curie, RDFa drafts, inconclusive...
DanC: I think we can leave this issue be until a new WD of RDFa and/or CURIEs comes out.
<ht> scribenick: ht
DC: TBL asked the question: Who
makes decisions about this sort of thing for the vendors?
... We're planning a f2f of the HTML WG for the Tech Plenary
week
... and we are hoping that there will be real technical
representation from all the vendors
<timbl_> "sensitive mode"
TBL: I think showing only a clean XML version of veiw sourcfe for copy/paste is non-destrictive
<Rhys> 'view problems' in the same sense as 'view source'?
DC: The best suggestion I've seen was to allow the "This is my content, show me problems rather than fixing me silently"
<timbl_> Firefox > Tools > Error Console
DC: Roy Fielding is taking the
HTML WG discussion seriously, but I don't know how far Ian
Hickson has yet succeeded in changing his mind
... Who knows how to make a private build of Firefox? None of
the people who do on the WG have stepped up so far. . .
... Boris Zbarsky seems like a candidate
TVR: yes...
<timbl_> http://mozillalinks.org/wp/2006/10/do-you-know-boris-zbarsky/
<ht_> web.mit.edu/bzbarsky/www/
<DanC> oh... timbl... what news on the blog URI?
<DanC> what is it you wanted to investigate?