See also: IRC log
<inserted> Scribe: Jonathan Rees
<inserted> Scribenick: jar
<noah> Henry: do you in fact have progress on 357 for today?
<noah> Hmm, that might be a sign of trouble.
<masinter> html-wg had zakim problems
<masinter> HTML_WG noted Zakim troubles too
Ashok is on the phone, as are Dan A, Larry, Jonathan, and Noah
Tim is on the phone
<ht_home> HST apologises for next week, will be in Hong Kong
noah: Election results are out http://www.w3.org/News/2010#entry-8694
... Reappointments: Ashok, Jonathan, Noah
<ht_home> HST thanks Noah for continuing to be willing to chair
<timbl> Welcome DKA!
<noah> My pleasure
<DKA> Thanks! great to be here.
<noah> Henry, do you have progress on 357
RESOLUTION: Approve minutes of 7 January 2010 http://www.w3.org/2001/tag/2010/01/07-tagmem-minutes
<noah> Henry, I would like you to take the lead on 357. Can't hear you.
<ht_home> I will hang up and redial
<ht_home> I sent email which hasn't made the ACTION!!!
<ht_home> First, wait for a pointer
<ht_home> This is expanded from the original QA post
<noah> Are you dialing?
<noah> The original QA post, which this revises, is at: http://www.w3.org/QA/2009/11/default_prefix_declaration.html
ht: Added motivation, listed some problems
... Please see section 3 re possible goals
ht: Narrowest possible goal is to inject namespaces only into the HTML serialization of HTML5
<noah> I'm intrigued that there isn't a goal 3: to bridge to goal #1 by supporting this new convention in the "XML" (as enhanced) as well the HTML serialization of HTML specifically.
ht: I don't think there will be interest in changing XML, so look at HTML5
... Narrow option would not apply to 'polyglot' (HTML/namespaced-XML) documents
... Also new in this draft: new bullets to the 'why prefixes' section
... The HTML serialization already specifies many prefixed attributes, e.g. xlink:href
... Prefix decl is allowed but not required
... There are also additions to section 7 questions and problems
... Documents that depend on some out-of-band prefix declaration are not, by virtue of that, ill-formed XML
... described mechanism would yield well-formed but not namespace-well-formed docs
... HTML5 lists the transition points between HTML and SVG (or MATHML). controlled by 'foreign' flag
... Error recovery is sensitive to whether you're in a foreign context
... Some SVG element names get camel-cased, while mostly names are uppercased
<noah> HT: For the examples in 7.5, add rel="prefix" to each link.
ht: Bug in example - all the links should have rel="prefix"
ashok: Why not be more ambitious - look at XML as well?
ht: If the HTML WG agreed to anything like this, it would happen relatively quickly. XML does not work on the same time frame.
... There's nothing in an XML document that says what version of the namespace spec it's conformant to
<Zakim> noah, you wanted to ask about the XML serialization of HTML in particular
noah: I [would] state more strongly that the XML *community* (not just WG) would hesitate
... Need to explain how do you take a document in one serialization and serialize it in the other
... or, maybe you can't do dpd in the XML serialization, but [scribe missed]
... Accept unbound prefixes?
<Zakim> Liam, you wanted to note that lack-of-static-scoping is status quo for XML today, and potentially status-quo for html5 today, whether good or bad, and that xml community seemed OK
liam: status quo for HTML5 is that you copy document fragments around, and the meaning might change
... Have been talking to people in XML communities, there's some support for changes provided we don't change the meaning of existing documents
<noah> I personally think that XML implementors are worried about more than changing the meaning of existing documents -- when some parsers start accepting new content, there's an expectaion that everyone's will.
noah: We've laid out 2-3 proposals, maybe we can look at pros & cons?
plh: What about the one from Microsoft? Why didn't you mention it?
<Liam> ms proposal http://lists.w3.org/Archives/Public/public-html/2009Sep/att-1216/MicrosoftDistributedExtensibilitySubmission.htm
ht: The MS proposal is like XML namespaces with a few things struck out
<Zakim> ht_home, you wanted to mention DanC's request wrt the requirements matrix
ht: In email announcing the new draft, Dan asked for the requirements matrix from the F2F to go into the DPD document
<noah> HT: Nuts, I used the wrong action number, which is why tracker didn't pick it up
ht: Columns are [namespace mechanisms], rows are [constituencies]
jar: check = meets that constituency's requirements, X = doesn't
ht: Problem with prefixes is that they're obtrusive, you have to keep typing them, even if the name is "in the language"
noah: Under DPD, all the SVG elements would have prefixes?
<masinter> The "mechanism to permit independently developed vocabularies" is being used to justify publishing microdata
<noah> NM: Do you have any defaulting at all Henry?
<noah> HT: No. In an HTML document, all SVG-namespace elements will likely have prefixes
<Zakim> masinter, you wanted to talk about microdata, rdfa, head/@profile, and other extensibility mechanisms in HTML
masinter: I argued that microdata was out of scope of the WG's charter
<noah> I'm not clear, Larry, on how what you're saying relates to the question on the table.
<noah> Ah, starting to get it.
masinter: taking a broader look: How many extensibility mechanisms does a language need?
... I'd like to have that discussion
... can we schedule that?
... See www-archive link pasted in above.
<masinter> ACTION: noah to schedule discussion of broader extensibility mechanisms question (including this) http://lists.w3.org/Archives/Public/www-archive/2010Jan/0043.html [recorded in http://www.w3.org/2010/01/14-tagmem-irc]
<trackbot> Created ACTION-374 - Schedule discussion of broader extensibility mechanisms question (including this) http://lists.w3.org/Archives/Public/www-archive/2010Jan/0043.html [on Noah Mendelsohn - due 2010-01-21].
caribou: we need consistency between XML documents and XML fragments in HTML documents
<noah> Yes, but XML does allow setting a default prefix, and it seems that DPD eliminates that capability, no?
<Zakim> DKA, you wanted to wonder if "it's not nice to type / look at them" is the only objection to namespaces...?
dka: Aren't there objections to namespacing that go beyond use of prefixes?
<noah> Perhaps this is what Carine is saying, but prefixing is not just syntactically clumsy, it's a level of abstraction that causes complexity and breakage (e.g. in copy/paste scenarios)
<caribou> The sticky namespace proposal is something like <prefix::element> and all children of "element" would be considered in the prefix namespace by default
ht: Some say the surface syntax is barbaric; other objection is from developers who say it makes dealing with the DOM a pain in the neck
<caribou> sticky namespace is just likely to introduce more breakage in copy/pasting fragments
ht: DOM-oriented developers want to just deal with local names. Anything that causes ambiguity is unacceptable
... but there are many more page authors than developers
ht: Any namespacing proposal will meet objections.
<Liam> <html>...<svg>... changes namespace in htlm5
plh: [sorry, scribe failed to summarize]
<noah> FWIW, languages like Java work both ways. It's certainly common to use import, which does bring new localnames into scope, but you can also reference (the analog of) expanded, fully-qualified names directly.
timbl: The HTML5 spec looks at design from the DOM point of view
philippe: In what namespace do attributes go? This is hard to understand
<trackbot> ACTION-357 -- Henry S. Thompson to elaborate the DPD proposal to address comments from #xmlnames and tag f2f discussion of 2009-12-10, particularly wrt integration with XML specs and wrt motivation -- due 2010-01-13 -- OPEN
noah: Not clear that the TAG will be taking this up again - no actions other than Henry's
<masinter> I think we should talk about this in the broad context of extensibility mechanisms in HTML, including RDFa, which addresses namespaces too
noah: Not closing 357. HT will put the matrix in the document
masinter: Maybe namespaces are disliked because other extensibility mechanisms are being proposed [to replace it].
liam: What to communicate to the HTML WG?
<caribou> extensibility in the html or in xml included in the html might not have the same impacts
ht: Is there an HTML WG issue open in this space?
plh: Yes, issue 41, still open
<noah> PLH: Still open, but no discussion happening. Chairs will likely bring it up and ask for concrete proposals within a month after raising it.
<noah> PLH: will close without prejudice after that unless there is a proposal on the table.
schedule ACTION-351 in two weeks
no objection to closing this issue.
<trackbot> ISSUE-30 Standardize a "binary XML" format? closed
<noah> scribenick: noah
JAR: I had made an assertion that HTTPbis has fixed this. That was called into question at the F2F. I took an action to research it, and I still think it's true.
... The question is, are 303 responses cachable? Answer seems to be identical to that for 302, I.e. yes if suitable headers are used.
... In short, I propose the TAG need not worry about this because HTTPbis has it under control.
... We should consider changes to ISSUE-57. Tempted to remove from issue description: how much history to retain.
<ht_home> HST is happy with the HTTPbis text at http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-8.3.4
NM: Suggest we keep history. Need an action to do it?
<jar> close ACTION-347
<trackbot> ACTION-347 Research 303 caching change in HTTPbis closed
JAR: Nah, small enough, trust me.
<ht_home> [HST leaves the call]
<scribe> scribenick: jar
<noah> # John Kemp email proposing updates to Authoritative Metadata: http://lists.w3.org/Archives/Public/www-tag/2009Dec/0128.html
johnk: I read through meeting minutes to find out what we decided. Seems sniffing does happen, and there's an IETF draft for how to do it safely. Consensus I think was that if you have to sniff, do it this way.
<noah> John Kemp email proposing updates to Self-Describing Web. See also responses from Larry (objecting to sniffing being promoted to architectural principle): http://lists.w3.org/Archives/Public/www-tag/2010Jan/0007.html
<noah> Noah response with counterpropsoal on SDW: http://lists.w3.org/Archives/Public/www-tag/2010Jan/0025.html
johnk: Looked for minimal edits to SDW to recognize this
<noah> Larry email saying "it shouldn't be arch principle": http://lists.w3.org/Archives/Public/www-tag/2010Jan/0018.html
<noah> Noah agrees: http://lists.w3.org/Archives/Public/www-tag/2010Jan/0019.html
masinter: Not sure I like the advice "if you're going to do it do it this way", prefer "is only OK in certain special contexts"
<noah> who hoo! Thank you Ralph! (Someone should make you the boss around here)
<masinter> thinks the exceptions to authoritative metadata each need to be fully justified in terms of actual experience in deployment; the "sniffing" draft contains several recommendations that are unjustified
<masinter> like sniffing Postscript and PDF...
johnk: I understood consensus as AM still stands
<masinter> not sure Barth is "least bad"
<noah> fair enough
noah: Let's look at AM
<noah> That is why [HTTPbis] states:
<noah> "If the Content-Type header field is not present, it indicates that the sender does not know the media type of the data; recipients MAY either assume that it is "application/octet-stream" or examine the content to determine its type."
<noah> SInce the examination of content to determine its type has a certain security risk (see [REF]) it is important that Web agents follow a common and secure algorithm such as [BarthSniff] for determining the content type.
<masinter> no content-type asserted anyway, sure. But [BarthSniff] hasn't been approved, i owe some review
johnk: The first edit (1.) is just to account for change to HTTPbis
<DKA> At the risk of opening up a can of worms, has the TAG considered the Mobile Web Best Practices working group's "Guidelines for Web Content Transformation Proxies" and its implications for content sniffing? : http://www.w3.org/TR/ct-guidelines/
masinter: three important cases: HTTP without a content-type, file:, and ftp: (the latter 2 also don't have content-type header)
<noah> Time check: 3 mins to go
johnk: AM says you should use HTTP so that you don't have to infer the content-type
<noah> DKA, would you mind sending an email to www-tag with pointer and brief summary?
masinter: I shouldn't have to run an HTTP server in order to say something about the metadata
<DKA> my first action!
masinter: What we say in general ought to be what bears in this particular case
noah: Worried about scope expansion
noah: The finding pretty much is what it is. Let's just tune what we have
<masinter> scope expansion seems like the right way of looking at difficulties
<masinter> think about ftp: and file: and file extensions, and which areas should metadata be authoritative. E.g., links with their own content-type which differs from HTTP's content-type header.
noah: Encourages everyone to reread AM with an eye to what Larry is saying (generalize to include file: )