W3C

- DRAFT -

TAG F2F Meeting

24 Mar 2010

See also: agenda, IRC log

Attendees

Present
Noah Mendelsohn, John Kemp, Ashok Malhotra, Jonathan Rees, Larry Masinter, T V Raman, Tim Berners-Lee, Dan Connolly, Dan Appelquist, Henry S. Thompson
Regrets
Chair
Noah Mendelsohn
Scribes
Dan Connolly (morning), John Kemp (afternoon)

Contents


Convene, review agenda

<DanC_> scribenick: DanC_

NM: we expect Paul Cotton and Sam Ruby for the joint session with the HTML WG chairs; we have regrets from Maciej
... note LMM is off to the IETF meeting tomorrow afternoon, so that's a constraint on the agenda

(NM notes a few other items on the agenda Revision: 1.36 of 2010/03/23 15:32:34 )

NM: the current agenda is biased toward the "let's not introspect much; just technical work, please" advice I've heard, but then more recently I've heard some call to take a look at the TAG mission

DKA: yes, as a new TAG arrival, some introspection looks useful
... I prepared some stuff on mobile as requested; looks like it's not yet on the agenda, presumably because I didn't notify you that it's done.

NM: [missed]

Joint session w/HTML WG Chairs

Sam Ruby, Mike Smith, and Philippe Le H├ęgaret arrive

NM: HT's travel has gotten complicated; he's delayed a few hours

NM: suggested topics?

PLH: (1) action items from TAG ftf in Nov ...
... (2) go over the list of issues, especially the ones we know the TAG is interested, as well as the others to make sure we didn't miss some that should be on the TAG radar

NM: also, there's been a request to talk about where the HTML WG is on the way to Last Call, CR, etc.

-> HTML 5 Update

PLH explains HTML WG decision process...

PLH: bugs are getting fixed about as fast as they arrive; the good news is that they're getting fixed; the bad news is that this projects time of LC never comes
... bug submission was facilitated by a quick-bug-submit form in the spec... such bugs are not attributed /anonymous

(much grumbling about anonymous contributions)

"Getting to Last Call" slide

PLH: rate-limiting factor seems to be accessibility issues

SR: there are 2 kinds of accessibility issues: (a) the technically complex ones, such as accessibility of canvas...
... and (b) technicall straightforward issues, such as whether alt text is mandatory, where consensus is harder to achieve in larger groups

LMM: [something about priority of market forces vs policy? scribe was behind]

<masinter> I wondered whether this was specifically an issue around accessibility, or if it was really a conflict between policy-based requirements vs. market requirements

<masinter> that some of the accessibility requirements came from trying to enforce a policy that wasn't directly a result of market forces but trying to do social re-engineering

SR: I strongly agree
... there's a line of argument that says "this technical feature has been in the spec for a decade and experience shows the market doesn't want to use it or can't use it productively"...
... some people use that argument _against_ mandatory-alt but not against presentational markup such as <canvas> [is canvas a typo? I think he gave a better example.]

Paul C. arrives

TBL: [not sure about the gist... something about the tension between acknowledging the importance of accessibility vs the technical awkwardness of making alt mandatory]

<rubys> validator messages for google.com, roughly sorted by category: http://intertwingly.net/stories/2010/03/20/www.google.com

LMM: is this restricted to accessibility issues? or are there more policy issues? the accessibility community is energized now, but we've seen similar issues around privacy
... also security... e.g. origin header

<masinter> security over origin header, stability through network gateways

TVR: as an end-user, alt on images that has frustrated me to no end... as an end-user, I couldn't care less. [struggling to paraphrase, so just recording verbatim]
... the hope for @alt was that authoring tools would prompt for alt text when images were added...

<timbl> TimBL: The mandatoriness of the ALT attribute is a unique case in the things the TAG has considered. It is very much of a political statement that accessibility is important. It encourages but does not force those who hand-edit a spec to include alt text. It encourages editors like Amaya to ask for it. There are many cases when the spec is not hand-edited. An editor can prompt for it anyway. There are many cases when it is important that the alt attribute v

<timbl> be an empty string. Before everyone accepted this as the benefit of encouraging ALT tag use was felt of overriding value.In these cases the document is made unnecessarily long, wasting time and space. As Larry says, the geopriv was similar case.

<timbl> We do after all have authoring tool guideliens.

<timbl> But we are not really talking about the ALT attribute, we are talking about the srt of problem which the HTML WG has with acc'y

TVR: but with workflows such as flicker, that's not a reasonable explanation

TVR: so if we could mark aspects of the language with good behaviour for authoring tools rather than constraints on the language, that seems a better way to go

<Zakim> DKA, you wanted to note an interesting parallel between alt tag discussion and geo api privacy discussion.

DKA: [... missed some] implementor notes in the spec about privacy issues [?]

DC: On alt and maybe others, I was hoping HTML would say "optional, but see WCAG"

<timbl> See http://www.w3.org/TR/WAI-AUTOOLS/#gl-prewritten-descs

<timbl> Guideline 3. Support the creation of accessible content.

<timbl> (in Authoring Tool Accessibility Guidelines 1.0

<timbl> W3C Recommendation 3 February 2000)

<Zakim> noah, you wanted to discuss tools vs. people

NM: re implementor guidelines... perhaps there are times/places to mention tools...

NM: but mostly I'd rather you didn't mention tools but rather think of them as use cases...

NM: I think it's better to just say what's in the language and what's out

<johnk_> the problem is one where social policy is enforced in RFPs

raman: for the alt tag, I would agree, but wouldn't agree in general

<Zakim> rubys, you wanted to inquire about the IETF practice of BCP

SR: what about separating "best practices" e.g. "use css rather than <center> or <font>" from the core spec? would the TAG support that?

[poll gets truncated by meta discussion]

<timbl> My 2c: It is very important for the spec to point guidelines but it should not replicate the body of the advice, just the title.

<johnk_> separating best practices from the specific mechanisms used to support/enforce those best practices is a good idea

Joint session w/HTML WG Chairs: Escalated issues and change proposal status

<paulc> http://dev.w3.org/html5/status/issue-status.html

<rubys> http://www.w3.org/html/wg/tracker/issues/open and http://dev.w3.org/html5/status/issue-status.html

<rubys> http://dev.w3.org/html5/status/issue-status.html

<rubys> topic ISSUE-4 html-versioning

<rubys> ISSUE-9 video-accessibility

SR: I think that's in hand by the accessibility TF

<rubys> ISSUE-27 rel-ownership

SR: doubt this should be on the TAG radar; to summarize: the spec currently says "see this wiki"; others a have said "use an IETF registry"

TBL: that's architectural

<scribe> ACTION: DanC to track HTML WG ISSUE-27 rel-ownership [recorded in http://www.w3.org/2010/03/24-tagmem-irc]

<trackbot> Created ACTION-404 - Track HTML WG ISSUE-27 rel-ownership [on Dan Connolly - due 2010-03-31].

ACTION-404: Paul C agrees to notify the TAG about this

<masinter> i'm interested in discussing what I think are the higher-level positioning differences rather than the issues themselves

<rubys> ISSUE-30 longdesc

<trackbot> ACTION-404 Track HTML WG ISSUE-27 rel-ownership notes added

<rubys> ISSUE-31 missing-alt

<rubys> table-summary

<rubys> ISSUE-41 decentralized-extensibility

<masinter> i think the underlying issue for this one is "who controls"

LMM notes...

ACTION-396?

<trackbot> ACTION-396 -- Noah Mendelsohn to henry to draft emails for NM to send to HTML WG chairs and to Liam+MS authors encouraging a change proposal wrt distr. extensibility by 23 March -- due 2010-03-05 -- PENDINGREVIEW

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

<rubys> ISSUE-56 urls-webarch

LMM: urls-webarch seems to be on course

DC: estimated timeline for urls-webarch?

LMM: I think the HTML WG can treat the URI/IRI spec as orthogonal, so it can be done quickly in the HTML WG

<rubys> ISSUE-66 image-analysis

<rubys> ISSUE-74 canvas-accessibility

<rubys> ISSUE-78 urls-terminology

<rubys> ISSUE-80 title-alternative

<rubys> ISSUE-81 representation-vs-resource

<rubys> ISSUE-82 profile-disambiguation

<DanC> (I think it's pretty wierd to separate the 2 profile issues)

DC: is there another, lowered-number issue re profile? is that closed?

SR: yes, it's closed; the resolution is to not add head/@profile, but to put it in a separate spec

<rubys> ISSUE-84 legacy-doctypes

<rubys> ISSUE-85 anchor-roles

<rubys> ISSUE-86 atom-id-stability

<rubys> ISSUE-88 content-language-multiple

<rubys> ISSUE-104 sniffing-optional

<rubys> ISSUE-101 us-ascii-ref

<MikeS> about issue 99, Dublin Core uses meta/@scheme

NM reviews TAG actions filed under HTML 5 review product

LMM: I'd like to talk about things at a higher level... policy vs market needs... control going forward... the "evergreen WG" model... etc.

<masinter> policy vs. market needs

<masinter> backward compatibility vs. future

action-379?

<trackbot> ACTION-379 -- Larry Masinter to check whether HTML language reference has been published -- due 2010-05-21 -- OPEN

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

PaulC: we published that on [March 5?]

<timbl> 3- on 3

<rubys> http://intertwingly.net/blog/2010/03/20/Authoring-Conformance-Requirements

HTML WG joint session with chairs: high level topics

LMM: I was making a list of [html wg issues?] "who can make html 6?"...

TBL: this sounds like just life... i.e. something that happens any time you get more than one person involved in something

LMM: W3C can be a lever for parties that advocate for policy issues... privacy, i18n, etc. rather than approaching individual vendors...
... so rather than commenting a la "please change X to Y because we like it" but rather "please change X to Y because of this policy issue"

JK: but then aren't we arguing for people who should themselves be in the WG?

<masinter> modularity

<masinter> modularity requirements don't affect any particular group

TBL: I'm not persuaded there's a problem...
... there are people who feel strongly about those policies who do get involved...

<masinter> discussion of the nature of policies, the role of the TAG, and the nature of the kinds of comments we're making on HTML WG issues

TBL: people ref modularity in comments

<Zakim> DanC_, you wanted to ask PLH about US ASCII and to

DanC: I think it is really useful to get the people from those those companies building stuff other than browsers involved in issues, e.g. sniffing

<johnk_> +1 to getting others involved to be a concrete action that TAG members could undertake that would help in advocating for policy-type decisions in technical specs.

HTML WG co-chair joint session: xml/html co-existence

SR: trailing slashes on a small number of elements are allowed...
... this brings these worlds closer together...

SR: it's only on, e.g. <script> and <textarea>, the /> won't work in deployed software and hence the spec is unlikely to change in that respect

<Zakim> masinter, you wanted to ask whether this is the other side of XHTML's appendix on how to be HTML compatible?

SR: another aspect is character sequences that are valid in both XHTML and HTML but mean differen things; e.g. the 1st newline in <pre>

TBL: <tbody>

<rubys> http://wiki.whatwg.org/wiki/HTML_vs._XHTML

LMM: there was an appendix of XHTML that said how to write XHTML that was compatible with [deployed text/html usage]...

SR: there's sentiment that that appendix C failed; the spec doesn't even try now; in some sense that's a step backwards

<MikeS> I think as document such as the one that masinter describes would be more appropriate as a separate document, editing separately, not as part of the HTML5 spec itself

SR: my site [uses the same bytes for XHTML and HTML or something]

TBL: my requirement is [everybody talks at once]

<masinter> there be a requirement to define a polyglot set

TBL: e.g. for just tbody... there are 2 things you can do: (a) include <tbody> all the time; but that's a pain...
... or (b) ensure there are no scripts that depend on it...

<Zakim> plh, you wanted to ask polyglot

<Zakim> noah, you wanted to discuss form of conformance note

TBL: some prefer one way; some prefer the other way; so the spec should allow both [?]

<timbl> DanC, the request was to move on from Larry's issue by then. We have already

NM: sounds like there's some sentiment for asking for some document to be produced... anybody want to be more concrete?

<timbl> Why, PLH. if I don't use the DOM?

<timbl> I use it as a markup language

DKA: if what I heard is correct... > has to be escaped differently in XHTML vs HTML... that sounds like a big problem...

NM: well, nobody's proposing to fix it --

SR: or is he?

LMM: how hard would it be to [fix it]?

TBL: impossible, because --

SR: [on layering of javascript parsers and html parsers ]

<Zakim> DanC_, you wanted to note tbody xpath

<timbl> Larry, please scribe

danc: regarding tbody (and xxx) you can make sure your scripts work, but you can't keep other people's xpath from not working if you don't put in a tbody

DC: Tim, regarding TBODY in Xpath, just because you don't write a script doesn't mean other people won't look in your document using XPAth.

timbl: nice point

<masinter> (discussion about whether xpointer syntax can be used in fragment identifier)

(and whether it's relevant to text/html)

<masinter> timbl: at the moment, i use text/html and polyglot

<DanC> (there is (or was?) an XPath/HTML issue in the HTML WG... I wonder what became of that.)

discussion about fragment identifiers & use of xpointer

paulc: (asking for tag to read minutes from our Nov meeting & do XXX)

<paulc> http://www.w3.org/2009/11/05-html-wg-minutes.html#item02

noah: i thought we did what paulc is asking for

paulc: trying to page the tag back in

noah: hixie said "that's ambiguous, i'll fix it"

paulc: there was a reference to a set of rules for polyglot document.

<timbl> This? http://www.la-grange.net/2009/07/05/html5-xhtml5/

<DanC> +1 ask the HTML WG to do a Note a la "HTML 5 and XHTML 5 - one vocabulary, two serializations"

<rubys> timbl, I think that is NOT what you want

tim: would like this to be in TR space, not just hidden somewhere in minutes

<timbl> ... Thtis? http://wiki.whatwg.org/wiki/HTML_vs._XHTML

TBL, TVR agree

<masinter> sam: I think what Tim wants is a description of a set of .... (discussion of what polyglot could be)

+ HT

<plh> Sam: an HTML parser will load xmlns attributes are DOM attributes, and not as DOM NS properties

<plh> ... including xmlns="http://www.w3.org/1999/xhtml"

<rubys> turn http://wiki.whatwg.org/wiki/HTML_vs._XHTML into a note

<masinter> ask Sam & Tim to come to agreement on what needs to happen on polyglot, and bring back to TAG any questions

<timbl> I want theat there should be in TR space a document which specifies how I can create a set of bits which I can server EITHER as text/html OR as xhtml+xml, which will work in a browser in both bases. As Sam does on his web site.

<timbl> It will rule out certain features.

+1 ask the HTML WG for a note that explains, basically, what Sam does on his web site; i.e. the flip side of http://wiki.whatwg.org/wiki/HTML_vs._XHTML

<masinter> 1+ to timbl's suggestion

<noah> I want an action to put before tag the options for doing what Tim wants

<timbl> There may be more than one different recipe.

<DanC> +1 ask the HTML WG for a W3C WG Note that explains, basically, what Sam does on his web site; i.e. the flip side of http://wiki.whatwg.org/wiki/HTML_vs._XHTML

<timbl> PROPOSED: We want theat there should be in TR space a document which specifies how I can create a set of bits which I can server EITHER as text/html OR as xhtml+xml, which will work in a browser in both bases. As Sam does on his web site.

<timbl> PROPOSED: We want theat there should be in TR space a document which specifies how I can crteate a set of bits which I can server EITHER as text/html OR as application/xhtml+xml, which will work in a browser in both bases. As Sam does on his web site.

<timbl> ooops

<MikeS> .me wonders if anybody would be willing to volunteer to act as editor for that doc

<masinter> There might be some changes to HTML needed?

RESOLVED: We want theat there should be in TR space a document which specifies how I can crteate a set of bits which I can server EITHER as text/html OR as application/xhtml+xml, which will work in a browser in both bases. As Sam does on his web site.


. ACTION DanC: ask the HTML WG to do produce a WG Note that satisfied the document the TAG resolved it wants (sort about polyglot documents)

(that's not English, but I'll fix it)

<scribe> ACTION: DanC to ask the HTML WG to do produce a WG Note that satisfied the document the TAG resolved it wants (sort about polyglot documents) [recorded in http://www.w3.org/2010/03/24-tagmem-irc]

<trackbot> Created ACTION-405 - Ask the HTML WG to do produce a WG Note that satisfied the document the TAG resolved it wants (sort about polyglot documents) [on Dan Connolly - due 2010-03-31].

HTML chairs joint session: decentralized extensibility

ACTION-396?

<trackbot> ACTION-396 -- Noah Mendelsohn to henry to draft emails for NM to send to HTML WG chairs and to Liam+MS authors encouraging a change proposal wrt distr. extensibility by 23 March -- due 2010-03-05 -- PENDINGREVIEW

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

NM: we encouraged people to send proposals (http://lists.w3.org/Archives/Public/www-tag/2010Mar/0015.html )

close action-396

<trackbot> ACTION-396 Henry to draft emails for NM to send to HTML WG chairs and to Liam+MS authors encouraging a change proposal wrt distr. extensibility by 23 March closed

<rubys> follow four links in the last column of http://dev.w3.org/html5/status/issue-status.html#ISSUE-041

<noah> http://www.w3.org/html/wg/wiki/ChangeProposals/fixedprefixlikexml

<timbl> Change Proposal: "Proposal X", Registered XML-Style Namespace Prefixes

<timbl> Change Proposal: "Proposal Y", Hyphen-Separated Vendor-Prefixed Attributes

<timbl> Change Proposal: XML-style namespaces with some naming restrictions.

<timbl> Change Proposal: Generalize the mechanism used for SVG and MathML

<timbl> Change Proposal: There is no problem and the proposed remedy is to change nothing.

<noah> http://www.w3.org/html/wg/wiki/ChangeProposals/fixedprefixsimple

<noah> http://www.w3.org/html/wg/wiki/ChangeProposals/html:xmlns

<noah> http://www.w3.org/html/wg/wiki/ChangeProposals/extensionslikesvg

<noah> http://lists.w3.org/Archives/Public/www-archive/2010Mar/0030.html

issue status shows ~5 proposals (as noted above)

SR: re the one-serialization, same DOM idea we just talked about... that argues _against_ re-using XML namespace syntax...
... because colon-separated names will be parsed differently

TBL: Microsoft has announced support for XHTML, i.e. application/xhtml+xml ; the IE9 thingy-that-is-not-a-browser shows alpha support

PLH: error handling is novel... maybe they're still experimenting with that...
... it shows the part of the document up to the error, rather than a traditional "XML parse error on line XYZ"

<rubys> http://intertwingly.net/stories/2010/03/17/illformed.jpg

PLH: there's concern about the difference in behaviour here

TBL: the whole fork of HTML & XHTML .... 'what if' .... things might have been different

raman: two blockers: IE popped up a download, and second was IE behavior ...

SR: the HTML 5 spec defines the term "XHTML" as "content served as application/xhtml+xml"; so for the purposes of this discussion, let's get clear, please

TVR: I prefer to define XHTML as "well-formed documents that use the HTML vocabulary".

SR: what if you forget to quote an attribute? double-checking...

TVR: indeed, a document with such a well-formedness error I call HTML, not XHTML

<Zakim> noah, you wanted to ask Raman, are you expecting non-polyglot?

SR: I don't advocate that definition because people will write scripts with < in them and it won't work

[?]

<masinter> "What is a chair? What I'm sitting on is a chair. A stool is a kind of a chair. A three-legged stool with one of the legs missing is a broken chair, which is a kind of a chair except you can't sit on it. A tree that falls in the forest, which looks like a chair, but nobody sits on it... is it a chair?"

[discussion of how to bind/define "XHTML", parsing rules, DOM, etc. exceeds scribe bandwidth]

SR: IE9 currently treats well-formed XHTML 1.0-conforming stuff served as text/html using the HTML parsing rules; I obviously can't speak for that vendor, but I don't expect that to change..
... because of compatibility

<masinter> ack

HT: there are documents with .htaccess that says to serve them as application/xhtml+xml except to MS IE... [missed the main point; help?]

<MikeS> ht, I believe the schema spec is non-conformant text/html -- it has many instances of <a name="foo"/> -- which is not conformant in text/html

<Zakim> masinter, you wanted to review http://lists.w3.org/Archives/Public/www-tag/2010Mar/0043.html

LMM: as I say in 0043, we get into trouble by using terminology as if it's intrensic when it's extrinsic

<plh> the question is "Should text/html in HTML 5 provide support for XML namespaces in the syntax and the DOM tree?"

PC: I heard Tim saying MS IE9 support might change the game... does the TAG think that's the case? does that take pressure off? does that make the fork less wide?

TVR: it makes the fork wider

<DanC>+1 it makes the fork wider

TBL: to large organizations such as IBM and Microsoft, when rolling out new features... will <video> work with XHTML? If so, perhaps I don't have such a strong requirement for distributed extensibility in text/html...
... but I'm not holding my breath for that [verbatim; might be missing the gist]

TBL: [help? colon in tag... not using it for namespaces...] not many documents

SR: you'd be surprised... I think I have an example from a top-20 site...

PLH: opera tried to deploy XML namespaces in text/html that way... they found it too troublesome

<Zakim> noah, you wanted to answer paul

SR: the top-20 example is jotspot

<rubys> http://www.google.com/#hl=en&source=hp&q=xmlns%3D%22http%3A%2F%2Fwww.google.com%2Fns%2Fjotspot%22&btnG=Google+Search&aq=f&aqi=&aql=&oq=xmlns%3D%22http%3A%2F%2Fwww.google.com%2Fns%2Fjotspot%22&fp=ae8f9588018abe0f

<timbl> Google bought jotspot and so own the content and can fix it

<plh> timbl, I see content using jotspot on www.pitt.edu

<plh> they can fix the software though

NM: I think everybody thinks the text/html mime type is really important, for at least a decade or so...

NM: so when somebody wants to add, e.g. 3d video, must they come to a centralized forum, or are they free to innovate?
... so to answer your question, TimBL, I think it's important that something like one of these 3 proposals gets consensus

<Zakim> raman, you wanted to point that long-term, an architectural goal is the convergence of Web content rather than continuing the xml/html fork

raman: increases the pressure, doesn't decrease the pressure

TVR: i think having separate mime types converge over time is better [roughly]

<Zakim> masinter, you wanted to ask for authoring guidance, application to SVG & MathML & 3D graphics, RDFa, as noted in HTML working group charter

LMM: looking at the HTML WG charter, which speaks of extensibility in HTML, not XHTML...
... sounds like you're making progress...
... [missed his main point?]

<masinter> "The HTML WG is encouraged to provide a mechanism to permit independently developed vocabularies such as Internationalization Tag Set (ITS), Ruby, and RDFa to be mixed into HTML documents. Whether this occurs through the extensibility mechanism of XML, whether it is also allowed in the classic HTML serialization, and whether it uses the DTD and Schema modularization techniques, is for the HTML WG to determine."

LMM: maybe it's worth re-visiting the way SVG and MathML were integrated and using a generalized mechanism

<rubys> http://www.w3.org/html/wg/wiki/ChangeProposals/extensionslikesvg

SR: there's a change proposal along those lines. [cited above]

lmm: sounds like the working group is closer to meeting what the charter called for it to do, which doesn't reduce the priority

<MikeS> masinter, as far as the exact use cases in the statement you quote, we already have specs for integrating Ruby and RDFa (as far as ITS, no person or group has yet specifically asked the group to address that)

DKA: is it out of the question to say that text/html is extensible to a limited extent, but if you want more, you have to use application/xhtml+xml?

PLH: considering possibilities such as SMIL in HTML 6, I see backward compatibility problems...

<Zakim> ht_stanford, you wanted to argue the benefits of lightweight namespaces in their own right

HT: [missed some] in these proposals, there's something that will make XML better...

HT: if HTML adopts proposals that allow [something about popular prefixes or namespaces], I can see it getting integrated into XML

<raman> I strongly believe this is our last opportunity to fix this ---

noah: future proofing of language is important: if you want to add something in HTML6 and it would break, that would be bad.

NM: re which of these proposals the TAG supports, [stuff about tactics...]

noah: want to ask HTML WG to come up with clear analysis

<Zakim> noah, you wanted to talk about profile

<Zakim> DanC_, you wanted to say I haven't seen anything that looks likely

DC: Haven't seen anything that looks likely...I.e. meets compatibility constraints, interesting to me, get critical mass of support

<masinter> paulc: discussion of whether this is a political or technical extensibility mechanism

<timbl> The counter-proposal http://lists.w3.org/Archives/Public/www-archive/2010Mar/0030.html says <<The issue description says that "The HTML5 specification does not have a mechanism to allow decentralized parties to create their own languages, typically XML languages, and exchange them in HTML5 text/html

<timbl> serializations", but to all appearances this is a good thing, not a problem. Why would we want to encourage vendors to create proprietary languages and exchange them as text/html?>> which is a false argument as extensions may well be community-related such as Mathml, and not vendor proprierary at all. It is a core requirement on HTML that it should allow communities to define extensions for use by that community without asking the HTML WG.

PaulC: [something about the evergreen WG no-change proposal]

<Zakim> masinter, you wanted to ask HT if he can recall what he heard from Liam, and whether there might be some way of changing error recovery rules in XML or make them more explicit

<raman> A different perspective on the TAG's bar --- i disagree with Dan. I believe any proposal is better than what is in the spec.

I should clarify... I'd like to see decentralized extensibility happen; I probably won't oppose any of the proposals.

<scribe> ACTION: Noah get the TAG to evaluate the decentralized proposals in the HTML WG [recorded in http://www.w3.org/2010/03/24-tagmem-irc]

<trackbot> Created ACTION-406 - Get the TAG to evaluate the decentralized proposals in the HTML WG [on Noah Mendelsohn - due 2010-03-31].

lmm, what did you want to add about noah's action?

action-406: and the discussion of the proposals in the HTML WG

<trackbot> ACTION-406 Get the TAG to evaluate the decentralized proposals in the HTML WG notes added

Doctypes and Versioning

<johnk> scribeNick: johnk

NM: HTML has action on Larry to resolve HTML ISSUE-4
... HTML WG set a deadline to close this issue
... We told HTML WG we would respond by the end of this meeting

ACTION-364

ACTION-364?

<trackbot> ACTION-364 -- Dan Connolly to ask HTML WG team contacts to make a change proposal re issue-53 mediatypereg informed by HT's analysis and today's discussion -- due 2010-02-25 -- PENDINGREVIEW

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

<DanC_> close action-393

<trackbot> ACTION-393 Update HTML WG co-chairs along the lines of ... DOCTYPE... workflow... media type.. closed

<noah> http://www.w3.org/html/wg/tracker/actions/172

LM: HTML5 spec on DOCTYPE has changed, so I closed 172

<DanC_> 8.1.1 The DOCTYPE

(see above link for current text)

LM: ISSUE-4 is still open, ISSUE-84 already addressed

NM: is this OK?

LM: Would like TAG to look at change proposals for ISSUE-4

DC: should review the 8.1.1 HTML text

HT: If you allow 1.0 should also allow transitional et al

NM: this does seem to have been considered carefully

HT: choosing 2 of the 4 public ids for HTML does seem odd
... what happened to the much bigger list of ids?

LM: there's another section that deals with quirksmode
... attempt was to make those doctypes that triggered quirks mode non-conforming?

ISSUE-41?

<trackbot> ISSUE-41 -- What are good practices for designing extensible languages and for handling versioning? -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/issues/41

(review http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html)

DC: HTML 5 spec says all the font tag containing docs "become lies"; proposed replacement:

Serving a document as text/html licenses processing

by user agents as specified in this spec.

(specifically, section 8.2 Parsing HTML documents)

Documents served as text/html *should* conform

to the HTML 5 syntax, but consumers should beware

that existing content varies considerably; note especially

section 11 on Obsolete features.

<masinter> I like http://www.ietf.org/rfc/rfc2854.txt better

HT: would rather see this point to media types which HTML supercedes
... see http://www.ietf.org/rfc/rfc2854.txt for information about "legacy" documents

<masinter> http://www.ietf.org/rfc/rfc2854.txt

<masinter> http://tools.ietf.org/html/rfc2854

(reviewing RFC2854)

TVR: how do we expect the whole community to figure this when we have a hard time finding the relevant reference?

LM: structured as "interoperability considerations"
... yes, there's a public spec, but the MIME type reg tells you what you have to do
... can see updating this doc for HTML5
... ie. latest published specification is updated from 4.01 to 5

TBL: I don't like publishing separate registration from the spec.

JR: registry of media types will get you to the right place

HT: I understood you could do this in the relevant section of HTML5

LM: could take the text from the media reg and put it somewhere else

TBL: should be a master spec. media type reg _is_ the specification of the language, whether it's the cover page, or the full spec.
... otherwise there is the irresistable temptation to put stuff in one document and not the other

HT: Like Dan's proposal augmented with something like in RFC2854 that describes the relationship to previous versions of the language

TBL: should be clear to anyone reading the spec that old versionned documents are ok

HT: perfectly reasonable to say that HTML5 document doesn't contain features of HTML4
... side-effect of moving prose from media type spec to language

TBL: (something about text/html document vs. HTML5 document)

<masinter> normally mime types point to language series, where individual versions are distinguished by language version indicator

NM: I think it's important that layering is correct - there are two ways to make "font tag" legal

<Zakim> DanC_, you wanted to move to divide the question

<Zakim> masinter, you wanted to talk about version indicators relationship to conformance rquirements

LM: traditionally, MIME type points to a language _series_
... MIME type doesn't change when you change the language
... in the doc itself, it says what version it is
... allows you to version the language

<Zakim> noah, you wanted to ask about edge cases

LM: without DOCTYPE or other version indicator, you can't deprecate features from the language

<DanC_> masinter, I heard that as something of an argument against my proposal; I'm sympathetic, but I didn't quite hear an alternative proposal, if you made one

<DanC_> (I think our time is not well-spent word-smithing, since the HTML 5 editor is going to re-word anyway)

NM: if no doctype, SHOULD conform to HTML, may conform to others
... but be aware that same syntax in different versions may cause clients to interpret document in ways different than specified in the current language spec.

<DanC_> ("design point?" I only heard editorial changes. I guess I wasn't sufficiently tuned in)

NM: design point is whether doctypes go away

<masinter> this is another use case for DOCTYPE

<masinter> documents without a doctype, the intended version is ambiguous

<Zakim> jar, you wanted to suggest just citing 2854

NM: when doctype is not there, old constructs may be misinterpreted by new processors

<noah> I suggest that be stated explicitly

JR: minimum intervention for me would be to reference RFC2854
... can't cause old content to go from "OK" to "not OK"

<masinter> "Interoperability Considerations" are as much of a part of the MIME registration as the "Published Specifications"

LM: iop section of rfc2854 is normative, believis DanC thinks it's not

<DanC_> well, yeah, the considerations are part of the MIME registration, but it doesn't say that HTML 2 docs conform; it just says that consumers have to be bugward compatible if they want to read documents that are on the web

JR: these specifications don't have a "statute of limitations"

<masinter> making previously conforming documents non-conforming can be justified if they weren't actually implemented and deployed

JR: just have one sentence that there will be documents out there which follow old versions of the specification

<jar> danc: IETF made some content transition from "OK" to "not OK"

JR: would like to see the information about these old languages be traceable

<Zakim> ht, you wanted to (eventually) move to consideration of the large list of public identifiers in section 8.2.5.4 of the HTML5 spec

<Zakim> ht2, you wanted to point to the RFC about media type changes

<ht> http://lists.w3.org/Archives/Public/www-tag/2010Feb/0011.html

<DanC_> I think the business of making HTML 2 docs no longer conforming was an oversight; I was just disputing claims that it had never happened.

My understanding of the discontinuity wrt the text/html media type

registration prose is this:

1) Previous media type registrations for text/html have explicitly

grandfathered in documents allowed by all earlier registrations of

text/html;

2) IETF rules for media type re-registrations requires that sort of

grandfathering;

3) The current draft media type registration section of the HTML 5

spec. does _not_ contain any such grandfathering.

HT: media type registration rules REQUIRE you to do this for re-registration

TVR: this has to be done right simply for use by other protocols, WGs and so on

NM: any sympathy for my earlier suggestion?

HT: we've lived without such in RFC2854
... can we log DanCs current text against the HTML WG bug

LM: not happy with language around 'licenses'
... MIME reg is informative
... mime registration is descriptive of what senders mean

<DanC_> http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html

<Zakim> masinter, you wanted to repeat that documents without DOCTYPE or version identifiers are thus to be treated as ambiguous

<ht> ACTION to henry to propose an update to DanC's prose from http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html to explicitly reference or encorporate the HTML history, similarly to the way 2854 does

<trackbot> Sorry, couldn't find user - to

<ht> ACTION henry to propose an update to DanC's prose from http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html to explicitly reference or encorporate the HTML history, similarly to the way 2854 does

<trackbot> Created ACTION-407 - Propose an update to DanC's prose from http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html to explicitly reference or encorporate the HTML history, similarly to the way 2854 does [on Henry S. Thompson - due 2010-03-31].

NM: is there anything we should do before Friday for HTML WG?

<ht> tracker, action-407 due 2010-03-25

<masinter> action-407?

<trackbot> ACTION-407 -- Henry S. Thompson to propose an update to DanC's prose from http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html to explicitly reference or encorporate the HTML history, similarly to the way 2854 does -- due 2010-03-31 -- OPEN

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

<DanC_> action-407 due 25 March

<trackbot> ACTION-407 Propose an update to DanC's prose from http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html to explicitly reference or encorporate the HTML history, similarly to the way 2854 does due date now 25 March

<DanC_> close ACTION-364

<trackbot> ACTION-364 Ask HTML WG team contacts to make a change proposal re issue-53 mediatypereg informed by HT's analysis and today's discussion closed

<DanC_> ACTION-364: see action-407 for follow-up

<trackbot> ACTION-364 Ask HTML WG team contacts to make a change proposal re issue-53 mediatypereg informed by HT's analysis and today's discussion notes added

Web Application Architecture: Security, Policy & Privacy

JK: Thomas Roessler, Matt Womer join

<noah> http://lists.w3.org/Archives/Public/www-tag/2010Mar/0022.html

<DanC_> close ACTION-397

<trackbot> ACTION-397 Frame F2F discussion on geolocation and geopriv, with help from DKA closed

AM: Geoloc WG declined to add a "privacy hook" to the API
... even after receiving comments

http://lists.w3.org/Archives/Public/www-tag/2010Mar/0022.html

AM: I believe this issue will not go away

DA: reminding people about similarity of this issue to the <alt> discussion - "policy through tags"

AM: was told that some participants didn't want to put policy hooks into the API

TLR: some relation to DAP WG
... flag for 'high-accuracy' could be used for protecting privacy perspective
... ie. one could say "don't send high accuracy information, if not needed"

<DanC_> Dom's suggestion: http://lists.w3.org/Archives/Public/public-geolocation/2010Mar/0014

AM: I thought that even this had been requested, and then rejected?

<DanC_> matt on fuzzing: http://www.w3.org/2008/geolocation/track/issues/18

NM: guidance is "only give it if explicitly requested"?

MW: discussed "fuzzing" of location

<tlr> I said that the "high accuracy flag" is motivated by battery consumption -- cell phone network based location vs gps

<Zakim> masinter, you wanted to ask whether this is "mandating policy" as much as allowing a policy to be mandated, different from alt. This is about just saying there *is* an alt tag

LM: there's one question "does the img tag have an alt", a second whether a value is mandated

<tlr> can somebody clarify what the direction of the earlier discussion about alt was?

LM: one question is whether the API has a hook to send policy information

<Zakim> noah, you wanted to talk (as usual) about extensibility hooks

LM: which is different from the question "do you mandate use of that hook"

<jar> masinter: There's a difference between saying the API has to have a way to communicate policy (that the ALT tag exist), and requiring communication of policy using that mechanism (making the ALT tag required)

NM: my impression was that there was a difference within the community
... so make sure you have an extensibility mechanism
... and allow that extensibility to be able to have "must understand" semantics
... policy is decoupled from the technical mechanism

AM: you are suggesting one model of privacy
... geopriv guys have a different model

<Zakim> DanC_, you wanted to cover "... on their head" from the Doty et. al. article in case tlr doesn't cover it

<DanC_> <excerpt>

<DanC_> Related work on location privacy standards in the IETF Geopriv working group

<DanC_> takes a play out of the content management environment and builds a mechanism

<DanC_> through which users can attach policies to their location information. This

<DanC_> turns the standard processes of privacy law and practice that rely on entities

<DanC_> providing notice to users through privacy policies on web sites to which users

<DanC_> can choose whether to consent on their head.

<DanC_> </excerpt>

DC: arguments in the Doty et al paper, which align with arguments in the WG, suggested that the suggested mechanism ended up putting liability on the user agent, who would blame the UA

NM: only way to solve this without trusting the UA is to encrypt the data for the public key of the recipient

<Zakim> timbl, you wanted to ask about the order of magnitude of fuzzying typicall needde

<DanC_> (record of what I said isn't clear, which reflects a certain amount of unclarity in my head)

TBL: question about how well-defined "fuzzing" is

TLR: fuzzing ...is giving a non-accurate answer

<masinter> Privacy and how to accomplish it while retaining usability is an area of intense R&D. In the meanwhile, the API should allow for current known "best practice" to be implemented and deployed, even if there are possible new practices

TLR: how that is arrived at will vary

<DanC_> the Doty paper says "best practice" is the opposite of the way GEOPRIV works, right masinter ?

<masinter> "best current practice" emphasais on "current"

TLR: we didn't feel comfortable suggesting a method of fuzzing

<DanC_> I don't see how "current" argues for or against the way GEOPRIV works

MW: every answer comes with a piece in the response that suggests the response is 95% accurate

<masinter> if people don't really know how to do fuzzing, it can't be "best current practice", even if it might be better practice than "sending retention policy"

MW: if you don't ask for "high accuracy" you might still get high-accuracy data

<DanC_> ah. now I see, masinter

<Zakim> tlr, you wanted to talk about criteria for web sites

TLR: geoloc WD comment period has run out
... WG is ready to proceed further

<DanC_> (re 7 July last pub... more than 3 months. boo. hiss.)

TLR: have the group create a checklist during CR

<DanC_> (yes, showing that sites meet a checklist makes sense as a CR task)

TLR: and show a list of sites that implement the checklist

AM: that's not a requirement is it?

<matt> http://dev.w3.org/geo/api/spec-source.html#privacy_for_recipients

<masinter> are there any GeoPriv implementations?

DA: checklist is exactly the way we went in MWBP - ie. there is precedent for this approach

<Zakim> jar, you wanted to ask for side by side comparison

<matt> masinter, do you mean implementations of the work that has come out of the Geopriv group at the IETF?

<masinter> yes, matt

JR: what I would find helpful is a side-by-side comparison of ietf geopriv vs. what is in geoloc

<matt> masinter, I don't have a solid answer. I believe Cisco implements the Geopriv DHCP rfc in their SIP gateways or maybe phones.

JR: this comparison could then be applied in other circumstances

TLR: confused about the status of conversations between IETF, CDT and Geoloc WG

<DKA> Can I suggest that, following from jar's suggestion, we focus the discussion on what happens after geolocation 1.0?

AM: geopriv has made a spec. where they have a place for putting privacy preference-related information

<Zakim> masinter, you wanted to remind that interoperability between GeoPriv and GeoLocation was also an architectural interoperability consideration, e.g., implementation of SIPs?

MW: geopriv had a number of proposals
... first was like the existing geopriv method

<tlr> process question: are we talking about geolocation 1.0 or 2.0? and if 1.0, are we talking about a previously closed issue or about a new one?

MW: a compromise was made to get it down to two bits: transmit to 3rd parties, and rule on retention

<DanC_> (hmm... I earlier said "I don't think there's going to be a better design in the future" but the WG postponed the issues; i.e. they suggest that there may well be better designs in the future)

LM: there is an IOP consideration here - geopriv is deployed in some cases, how should geoloc and DAP interoperate?

<noah> We have 12 mins -- working toward wrapup or next steps would be good.

LM: really looking at such IOP scenarios will help to determine what to do with this issue
... on fuzzing: there's best current practice and "future better practice"

<matt> [[Background on geopriv proposals: the first had a number of things in it, including an XML policy blob, there was some evolution, but the latest proposed just two attributes: retransmission to third parties, and how long location information can be stored.]]

LM: it may be that best current practice is to have some bits in your responses that specify your privacy preference
... better future practice may be to support privacy via fuzzing (or other methods)
... but shouldn't remove the possibility to support best current practice \

<matt> [[Just to be clear: the API makes no restrictions on the accuracy of the information sent now, and allows for it to be completely fictional]]

DA: best use of our time is to figure out what to do after geoloc 1.0

<tlr> +1 to that

<masinter> may be some disagreement about what "best current practice" is, but "no practice" isn't acceptable

<DanC_> (that's a good way to put it...)

<DanC_> (the user agent doesn't want to present the question when it's actually the remote end that's asking)

<DKA> https://wiki.mozilla.org/Drumbeat/Challenges/Privacy_Icons

DA: pushback was about it being disingenuous to present a question to the user which couldn't be enforced

<matt> [[please also note that most implementations are receiving location information from a third party, and thus the browser can't promise that the information that they receive has not already been compromised]]

<DKA> http://www.betavine.net/bvportal/resources/location

DA: this information (above) would be useful for DAP and next version of geoloc

NM: DAP WG is looking at this issue, Frederick (chair) sent a message to us about this
... they published a strawman approach, which we responded to

<DanC_> (has the IETF said whether they're satisfied with the geolocation WG's response to their comments?)

TLR: that group (DAP WG) had f2f last week, and there is now an editor's draft of privacy reqs for DAP

<DanC_> "that group"?

<jar> http://dev.w3.org/2009/dap/policy-reqs/

<DanC_> ah. tx.

TLR: not always obvious what these requirements mean when related to APIs

<jar> http://dev.w3.org/2009/dap/privacy-reqs/

MW: my gut feeling is that precise lat long information is one of the hardest things to make "privacy sensitive"

DC: ie. "fuzzing is hard" - this stuff is a research issue

TBL: there are lots of ways to do it, but some of them aren't research topics - they can be done easily
... whereas fuzzing civic address data could be actually trickier

AM: with fuzzing I can request country or town - can (from the responder) I say give a fuzzy location?

MW: API doesn't restrict this - "you can lie"

TBL: I don't like that we design a system where lying is possible

TLR: possibility to lie gives the user autonomy

<matt> http://dev.w3.org/geo/api/spec-source.html#introduction

TLR: "the API is agnostic to the information source"

<matt> [[The Geolocation API defines a high-level interface to location information associated only with the device hosting the implementation, such as latitude and longitude. The API itself is agnostic of the underlying location information sources. Common sources of location information include Global Positioning System (GPS) and location inferred from network signals such as IP address, RFID, WiFi and Bluetooth MAC addresses, and GSM/CDMA cell IDs, as well as user inp

<matt> guarantee is given that the API returns the device's actual location.]]

<Zakim> DKA, you wanted to propose a workshop or some other kind of way to socialize this issue and help with clarity - in line with my previous comments.

<DanC_> (phtpht. queue bug at 14:57)

DA: this seems to be an area where we could show leadership in the community
... would it make sense to convene an industry workshop?

<DanC_> (that long list of complications would have been nice to record; shows depth of DKA's backround. too back it's already leaked out of my brain)

DA: where we could get implementation experience and relevant research

<DanC_> . ACTION DKA: look into next steps on a workshop around device privacy etc.

action dan appelquist to further discussion of a w3c workshop in the area of web APIs privacy

<trackbot> Sorry, amibiguous username (more than one match) - dan

<trackbot> Try using a different identifier, such as family name or username (eg. connolly, dappelqu)

<DanC_> . ACTION DKA: look into next steps on a workshop around device privacy etc.

<DanC_> . ACTION DKA: look into next steps on a workshop around device APIs, privacy etc.

<DanC_> ACTION: DKA to look into next steps on a workshop around device APIs, privacy etc. with tlr [recorded in http://www.w3.org/2010/03/24-tagmem-irc]

<trackbot> Created ACTION-408 - Look into next steps on a workshop around device APIs, privacy etc. with tlr [on Daniel Appelquist - due 2010-03-31].

DC: WG has essentially postponed this issue - suggests they think a better design is coming along
... I would suggest no TAG action that's critical to CR

<DanC_> DC: collecting experience in CR seems like a reasonable next step

NM: thanks Matt & Thomas

(break) Matt Womer and Thomas Roessler depart

<jar> http://www.kendallhotel.com/dining-events/dinner-menu/

NM: propose we switch admin topics with ISSUE-27 agenda items
... would like to take up admin issues

Administrative issues

NM: next f2f meeting?

<amy> say my name when you want and I'll pay attention

(discussing scheduling)

<DanC_> 7-9 Jun in the UK is a proposal; likely regrets from 1 member

<DanC_> west coast in June has been moved and 2nded

<DanC_> 2-4 June... (west coast?)

2-4 June, west coast USA is also a proposal

fewer people can reliably make that

DanC: do a video-conf type meeting?

TVR: how about a split meeting - those who can make it to west coast do so, those to UK do so, we overlap for some timezone-useful period of time

LM: either gather f2f as a whole group, (and/) or schedule more, longer telecons

some consensus for UK, 7-9 June

<DanC_> with regrets from 1

<DanC_> and another 2 at risk

proposal: 7-9 June, London

RESOLUTION: face-to-face meeting, 7-9 June, London

NM: TPAC is in Lyon, France
... NM: 1st week Nov
... do we need to re-arrange the agenda?

LM: propose to swap ISSUE-57 with ISSUE-54

<DanC_> . close ACTION-356

HTML 5 Decentralized Extensibility (ISSUE-54)

<DanC_> action-406?

<trackbot> ACTION-406 -- Noah Mendelsohn to get the TAG to evaluate the decentralized proposals in the HTML WG -- due 2010-03-31 -- OPEN

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

<DanC_> close ACTION-356

<trackbot> ACTION-356 Work with Carine Bournez to schedule followup meeting on xmlnames followup discussion closed

close ACTION-356

<trackbot> ACTION-356 Work with Carine Bournez to schedule followup meeting on xmlnames followup discussion closed

<DanC_> action-357: possibly subsumed by action-406

<trackbot> ACTION-357 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 notes added

NM: propose HT does follow-up on 357

<DanC_> ACTION-357 due next week

<trackbot> ACTION-357 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 date now next week

<DanC_> (i.e. sometime in the future)

close ACTION-374

<trackbot> ACTION-374 Schedule discussion of broader extensibility mechanisms question (including this) http://lists.w3.org/Archives/Public/www-archive/2010Jan/0043.html closed

close ACTION-396

<trackbot> ACTION-396 Henry to draft emails for NM to send to HTML WG chairs and to Liam+MS authors encouraging a change proposal wrt distr. extensibility by 23 March closed

<DanC_> ACTION-113?

<trackbot> ACTION-113 -- Henry S. Thompson to hT to a) revise composition.pdf to take account of suggestions from Tim & Jonathan and feedback from email and b) produce a new version of the Elaborated Infoset finding, possibly incorporating some of the PDF -- due 2010-04-01 -- OPEN

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

<DanC_> HT: yup, don't delete 113

NM: move ISSUE-57 to Thursday

IRIEverywhere

<noah> http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037.html

NM: there is a proposal for closing it (see above)

LM: we have to replace stable refs
... staging timeline of HTML, LEIRI is different
... create a document containing current content, but mention the new document

XML CORE should work in the following phases:

1. Develop a draft of what a replacement to [LEIRI] would look like,

given the current content of IRI-BIS. Coordinate with IRI-WG if any

changes are needed to IRI-BIS, and continue to track IRI-WG.

2. Publish a new version of [LEIRI] as an updated NOTE with both the

current content and the proposed new content.

<masinter> http://tools.ietf.org/html/draft-ietf-iri-3987bis-00

3. When IRI-BIS is approved for standards track in IETF (either at

"Draft Standard" or restarted at "Proposed Standard" level), remove

the older content of [LEIRI] and leave the pointer to the new (stable)

IRI-BIS document.

<masinter> look at http://tools.ietf.org/html/draft-ietf-iri-3987bis-00#section-7.1

HT: is this a matter for liaison between XML Core and IETF?

<masinter> secton 7.1 talks about LEIRI processing

LM: yes

<DanC_> . ACTION HT: run this plan by the XML Core WG

NM: are you proposing to cut detailed discussion from TAG?

HT: would like Larry to send his proposal to XML Core WG

<noah> Please s/this/Larry plan for closing ISSUE 27/

LM: new document describes a transformation process, rather than non-terminal in a BNF grammar

HT: XML Core is the right place to review this

<DanC_> ACTION: HT to run Larry's plan for closing IRIEverywhere by the XML Core WG [recorded in http://www.w3.org/2010/03/24-tagmem-irc]

<trackbot> Created ACTION-409 - Run Larry's plan for closing IRIEverywhere by the XML Core WG [on Henry S. Thompson - due 2010-03-31].

<masinter> section 1.3 should contain definition: LEIRI (Legacy Extended IRI): This term was used in

<masinter> various XML specifications to refer to strings that, although not

<masinter> valid IRIs, were acceptable input to the processing rules in

<masinter> Section 7.1.

HTML WG should follow the following phases:

1. Confirm that a document, even with a normative reference to a work

<scribe> in progress, can enter Candidate Recommendation state, and that

advancement of IRI-BIS to IETF standards track is not a 'blocking'

issue. (Otherwise the contingency plan in step 3 will need to be done

sooner.)

2. Prepare a version of the HTML specification that references a

specific version of IRI-BIS, noting that the document is evolving.

3. When preparing HTML5 for Proposed Recommendation, update the

reference to IRI-BIS as needed: if the IETF IRI WG succeeds in

completing its work in time, that can be used as a stable

specification; otherwise, implement a contingency plan following the

LEIRI development plan above: create a Working Group Note that

describes a current reference to IRI-BIS, along with a copy or update

of the WEBADDR specification.

close ACTION-398

<trackbot> ACTION-398 Prepare plan for resolving issue-27 IRIEverywhere for F2F discussion closed

LM: Is there anywhere else where we need to update these references?

<DanC_> . ACTION Larry: let the TAG know that the IRIEverywhere plan in HTML WG went as planned

DC: RDFa?

<DanC_> ACTION: Larry to let the TAG know that the IRIEverywhere plan in HTML WG went as planned [recorded in http://www.w3.org/2010/03/24-tagmem-irc]

<trackbot> Created ACTION-410 - Let the TAG know that the IRIEverywhere plan in HTML WG went as planned [on Larry Masinter - due 2010-03-31].

DC: should we close the issue?

<DanC_> PROPOSED: whereas the plan http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037.html looks credible, to close IRIEverywhere

<noah> +1

NM: risk in closing the issue is that something objectionable happens, but expect that someone here notices

<noah> Note that having no actions means the chair anticipates no followup at this time.

<DanC_> DC: note the risk that the HTML WG might want the IRI details nailed before last call... but I guess that risk is pretty remote

<DanC_> noah, note we have 2 open actions

<DanC_> 409 and 410

<noah> Never mind.

<DanC_> LMM: note various risks getting IRI stuff thru the IETF, due to all sorts of hair around IDNA, low participation, etc.

LM: there are some risks in the IETF process for this document

TVR: so, do we feel comfortable enough that this plan will succeed, since HTML depends on it?

LM: transition plan does depend on whether HTML can go finished LC with normative ref to an I-D

<masinter> the risks aren't really IETF risks, they're technical risks

<masinter> and they need to be resolved in IETF or HTML, venue is better, not worse

<DanC_> issue-27?

<trackbot> ISSUE-27 -- Should W3C specifications start promoting IRIs? -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/issues/27

RESOLUTION: whereas the plan http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037.html looks credible, to close IRIEverywhereClose ISSUE-27 IRIEverywhere

<DanC_> RESOLVED: whereas the plan http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037.html looks credible, to close IRIEverywhere

<DanC_> ACTION: Larry take the next step on announcing IRIEverywhere [recorded in http://www.w3.org/2010/03/24-tagmem-irc]

<trackbot> Created ACTION-411 - Take the next step on announcing IRIEverywhere [on Larry Masinter - due 2010-03-31].

LM: should tell the community that we plan to close this issue, but note that not all the work required is complete

close action-383

<trackbot> ACTION-383 Review DanC's email on speaks_for closed

<DanC_> close ACTION-383

<trackbot> ACTION-383 Review DanC's email on speaks_for closed

ADJOURNED

Summary of Action Items

[NEW] ACTION: DanC to ask the HTML WG to do produce a WG Note that satisfied the document the TAG resolved it wants (sort about polyglot documents) [recorded in http://www.w3.org/2010/03/24-tagmem-irc]
[NEW] ACTION: DanC to track HTML WG ISSUE-27 rel-ownership [recorded in http://www.w3.org/2010/03/24-tagmem-irc]
[NEW] ACTION: DKA to look into next steps on a workshop around device APIs, privacy etc. with tlr [recorded in http://www.w3.org/2010/03/24-tagmem-irc]
[NEW] ACTION: HT to run Larry's plan for closing IRIEverywhere by the XML Core WG [recorded in http://www.w3.org/2010/03/24-tagmem-irc]
[NEW] ACTION: Larry take the next step on announcing IRIEverywhere [recorded in http://www.w3.org/2010/03/24-tagmem-irc]
[NEW] ACTION: Larry to let the TAG know that the IRIEverywhere plan in HTML WG went as planned [recorded in http://www.w3.org/2010/03/24-tagmem-irc]
[NEW] ACTION: Noah get the TAG to evaluate the decentralized proposals in the HTML WG [recorded in http://www.w3.org/2010/03/24-tagmem-irc]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/04/05 21:03:43 $