Draft minutes of TAG telcon 2010-01-14

Draft minutes of last week's TAG teleconference are here

http://www.w3.org/2001/tag/2010/01/14-minutes.html

and below.  -Jonathan

W3C
- DRAFT -
TAG Weekly
14 Jan 2010

Agenda

See also: IRC log
Attendees

Present
    HT, Dan_Appelquist, Jonathan_Rees, Masinter, Ashok_Malhotra,
John_Kemp, TimBL, noah, Liam_Quin, Carine_Bournez
Regrets
Chair
    Noah Mendelsohn
Scribe
    Jonathan Rees

Contents

    * Topics
         1. Convene
         2. Approve minutes of 7 January 2010
         3. Name qualification mechanisms for HTML 5 (xmlnames)
         4. Binary XML
         5. Research 303 caching change in HTTPbis
         6. Propose updates to Authoritative Metadata and
Self-Describing Web to acknowledge the reality of sniffing
    * Summary of Action Items

<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
Convene

<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
Approve minutes of 7 January 2010

<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
Name qualification mechanisms for HTML 5 (xmlnames)

<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> http://www.w3.org/2001/tag/doc/dpd.html

<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

<timbl> (I can challenge by the way "Of these, the first is arguably
the more significant, because the number of authors exceeds the number
of developers by a large margin. " because many authors don't see the
tags, and those that do a proportion hack the javascript. But not all
authors see tags and not all people who use js are site developers.)

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

cat: meow

<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?

noah: Unintentional

<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

<noah> http://www.w3.org/2001/tag/2009/12/Whiteboard.jpg

<ht_home> http://lists.w3.org/Archives/Public/www-tag/2010Jan/0055.html

ht: In email announcing the new draft, Dan asked for the requirements
matrix from the F2F to go into the DPD document

<ht_home> http://www.w3.org/2001/tag/2009/12/Whiteboard.jpg

<noah> HT: Nuts, I used the wrong action number, which is why tracker
didn't pick it up

<masinter> http://lists.w3.org/Archives/Public/www-archive/2010Jan/0043.html

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

<Zakim> Liam, you wanted to enumerate (1) javascript api probs, (2)
syntax, (3) "nothing there"-ness

ht: Any namespacing proposal will meet objections.

<Liam> <html>...<svg>... changes namespace in htlm5

<caribou> http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#foreign-elements

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
... you're making a finer distinction, the people writing tags out,
and those writing javascript

philippe: In what namespace do attributes go? This is hard to understand

<masinter> action-357?

<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

<trackbot> http://www.w3.org/2001/tag/group/track/actions/357

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> http://www.w3.org/html/wg/tracker/issues/41

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
Binary XML

no objection to closing this issue.

close ISSUE-30

<trackbot> ISSUE-30 Standardize a "binary XML" format? closed
Research 303 caching change in HTTPbis

<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
Propose updates to Authoritative Metadata and Self-Describing Web to
acknowledge the reality of sniffing

<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!

<timbl> :)

masinter: What we say in general ought to be what bears in this particular case

noah: Worried about scope expansion

masinter: Why?

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: )

ADJOURNED
Summary of Action Items
[NEW] 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]

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/01/20 02:03:40 $

Received on Wednesday, 20 January 2010 02:07:47 UTC