minutes TAG meeting Nov 2, 6 in Santa Clara

By reference, in hypertext:
  http://www.w3.org/2001/tag/2009/11/02-agenda.html
  http://www.w3.org/2001/tag/2009/11/02-minutes.html
  http://www.w3.org/2001/tag/2009/11/06-minutes.html

By value, for tracker, archive search, etc.

[1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

        TAG meeting during Santa Clara TPAC, part 1 (Monday AM)

02 Nov 2009

   [2]Agenda

      [2] http://www.w3.org/2001/tag/2009/11/02-agenda.html

   See also: [3]IRC log

      [3] http://www.w3.org/2009/11/02-tagmem-irc

Attendees

   Present
          Noah_Mendelsohn_(NM), TV_Raman_(TVR), Henry_Thompson_(HT),
          Larry_Masinter_(LMM), Ashok_Malhotra_(AM), Dan_Connolly_(DC),
          TimBL

   Regrets
          John_Kemp, Jonathan_Rees

   Chair
          Noah Mendelsohn

   Scribe
          Larry Masinter, DanC

Contents

     * [4]Topics
         1. [5]Convene, review records and agenda
         2. [6]privacy policy (Device APIs)
         3. [7]coordination with Webapps on CORS: preparation
         4. [8]coordination with Webapps on CORS: joint session
         5. [9]Discussion topics with HTML WG on Thursday: text/html
         6. [10]Discussion topics with HTML WG on Thursday: data
         7. [11]Discussion topics with HTML WG on Thursday: authoring
            spec
         8. [12]Disucssion with HTML WG chairs
     * [13]Summary of Action Items
     _________________________________________________________

Convene, review records and agenda

   <ht> scribe: Larry Masinter

   <ht> scribenick: masinter

   nm: invited HTML-WG chairs at 3:30

   TVR: at-risk for Fri
   ... regrets 12th Nov

   nm: the rest of TAG who haven't should review status of open issues
   that they are shepherd for by 10th Nov, please.
   ... future F2F meetings review (see agenda)
   ... TAG call for nominations posted

   RESOLUTION: minutes from 23-25 Sep F2F approved
   ... minutes of october 8 approved
   ... minutes of October 22 approved

   see agenda for references to minutes

privacy policy (Device APIs)

   action-318?

   <trackbot> ACTION-318 -- Noah Mendelsohn to send note to Device APIs
   and Policy (DAP) Working Group on behalf of the TAG -- due
   2009-10-25 -- OPEN

   <trackbot> [14]http://www.w3.org/2001/tag/group/track/actions/318

     [14] http://www.w3.org/2001/tag/group/track/actions/318

   action-321?

   <trackbot> ACTION-321 -- Noah Mendelsohn to bug Larry about his
   input to ACTION-318 -- due 2009-10-29 -- OPEN

   <trackbot> [15]http://www.w3.org/2001/tag/group/track/actions/321

     [15] http://www.w3.org/2001/tag/group/track/actions/321

   action-321 was reassigned to lmm

   <DanC> action-321?

   <trackbot> ACTION-321 -- Larry Masinter to lightly edit TAG input to
   DAP WG per 8 Oct and tell Noah -- due 2009-10-29 -- OPEN

   <trackbot> [16]http://www.w3.org/2001/tag/group/track/actions/321

     [16] http://www.w3.org/2001/tag/group/track/actions/321

   <DanC> (lmm, actions/321 has a link to the note to edit in the
   comments)

coordination with Webapps on CORS: preparation

   Art Barstow invited TAG to come down to talk to WebApps, discussing
   whether we want to have that meeting

   <jar> blast. wish I could

   <DanC> [17]CORS: email from Henry Thompson re "CORS still not
   getting to closure"

     [17] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0316.html

   <DanC> HT relayed the TAG's request for an issue; the chair,
   Barstow, forwarded it to the group; the folks with concern about
   confused deputy don't seem to be stepping forward to say "yes, we
   want an issue"

   ht: My email asked them to open an issue. But my reading of the
   thread that followed didn't pile in and say 'yes'

   <jar> Mark M is away from email for a couple of weeks

   <jar> I don't know about Tyler, and I haven't weighed in because I
   don't know what to add (and I'm not on the WG)

   <jar> MM said on the list that he'd be gone and that he looks
   forward to a discussion when he returns

   <noahm> LM: There's the technical issue, but also process issue as
   to whether WebApps is the right place to settle this security
   design.

   <noahm> LM: Also, Thomas Roessler is organizing a lunch on Thursday
   to discuss web security

   <jar> the last message on the thread basically said unguessable
   tokens was best practice, and should be used in *addition* to cors.
   I contemplated a response saying why do you need Origin: if you're
   using unguessable tokens, but haven't figured out how to say this in
   a constructive way

   <jar> it's hard to participate given limited time

   <masinter_> [18]Poll: Security get-together at TPAC

     [18] http://doodle.com/ev7m8nvww3dw42k6

   Thursday lunch meeting on web security

coordination with Webapps on CORS: joint session

   <DanC> [19]CORS item in Web Applications Working Group 2 Nov minutes

     [19] http://www.w3.org/2009/11/02-webapps-minutes.html#item03

   <DanC> [20]WebApps WG 'confused deputy problem' issue

     [20] http://www.w3.org/2008/webapps/track/issues/108

Discussion topics with HTML WG on Thursday: text/html

   <DanC> scribe: DanC

   on text/html... and "XHTML" served as...

   TBL: proposed requirement: XHTML served as text/html should work

   DanC: that's not feasible

   TBL: I'm doing it; it works

   NM: clarify, please?. "Works" means is interpreted as it would be as
   application/xhtml+xml?

   DanC: you're not doing it in the general case; you stated the
   requirement in the general case

   HT: what doesn't work?

   DanC: <blockquote />

   HT: There's a well-documented set of constraints

   NM: So, Dan, when you say it's infeasible, you're saying "browsers
   already interpret text/html in a way that conflicts with being
   compatible with application/xhtml+xml"

   DC: Yes, see example of <BLOCKQUOTE /> above

   LMM: I come back to the point that IETF requires that old content
   not be invalidated by new specs. [roughly]
   ... currently, the spec goes against that.

   <masinter> One possible requirement for re-registering a media type
   is that a new update should not make previously valid content
   invalid.

   <masinter> Previously valid content included XHTML to be served as
   text/html, as well as consistent versions.

   <noahm> FWIW, I would like to converge ASAP on: "Here's what the TAG
   wants to achieve on this during our Thurs. discussion:

   TBL: that's not the HTML WG change policy; their change policy for
   changes is "we'll consider the costs/impact", not 100% backward
   compat

   LMM: but you can't redefine the media type

   DC: I think the WG has accepted that. Old stuff that broke that is
   now viewed as bugs.

   LMM: they've accepted it to some degree, but it doesn't give a
   coherent view of HTML 2, for example. [something like that]

   <Zakim> DanC, you wanted to visit "well-documented set of
   constraints" and to speak to the new/old invalid

   DC: Henry, you said there is a well doc'd set of constraints. There
   isn't, but that would be a good goal.

   HT: What's in the spec isn't good enough.

   DC: Not cited by HTML 5, disputed.

   HT: Works for me.

   DC: Me too.

   HT: Is it in the current media type registration?
   ... there's the architectural/versioning aspect of this that LMM is
   speaking to...

   <masinter> "The text/html media type is now defined by W3C
   Recommendations;

   <masinter> the latest published version is [HTML401]. In addition,
   [XHTML1]

   <masinter> defines a profile of use of XHTML which is compatible
   with HTML

   <masinter> 4.01 and which may also be labeled as text/html."

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

     [21] http://www.ietf.org/rfc/rfc2854.txt

   NM: Do we know what to ask for?

   DC: Maybe, recruit a writer to write up ...????

   HT: what I want is: in the case where the content starts with an XML
   declaration, parse it with an XML parser

   (poll for support around that)

   (discussion of label conforming ....)

   <Zakim> masinter, you wanted to ask for something else

   [missed exchange]

   LMM: I don't think conformance requirements stated in terms of how
   it's processed is [good]

   NM: I meant it as a shorthand

   LMM: the "appendix C" was an intersection... until XHTML is
   well-deployed
   ... the question is whether anything in HTML5 [breaks] this

   TBL: I don't want a "switch"...
   ... I want people to be able to incrementally tidy things up

   <masinter> in HTML4 there was a set of documents in the intersection
   of HTML4 and XHTML such that documents in the intersection could be
   interpreted EITHER as XML *OR* as HTML, and that it wouldn't matter
   how it was processed.

   <masinter> We are asking for HTML5 to retain that there is a useful
   subset in the intersection of HTML5 and XHTML

   <ht> The above URI [22]http://hixie.ch/advocacy/xhtml is Hixie's
   old, but somewhat updated, argument against _serving_ XHTML as
   text/html

     [22] http://hixie.ch/advocacy/xhtml

   <ht> I think it's actually mostly irrelevant as an argument against
   'sniffing' and then _parsing_ some text/html as XHTML

   <DanC_> [23]let authors choose text/html or application/xhtml+xml
   (detailed review of section 1. Introduction)

     [23] http://lists.w3.org/Archives/Public/public-html/2007Aug/1188.html

   <DanC_> ^^ that comment is still pending:

   (discussion of W3C web site that have .htaccess depending on browser
   sniffing to serve the same documents in appendix C subset as
   text/html or application/xhtml+xml)

   <noahm> Am I confused, I thought that question was whether it is
   legal to send <p>XXX</p> as text/html (I.e. because it happens to be
   well formed XML)

   [scribing lightly until we get closer to a conclusion...]

   <noahm> Why can't this be text html? <p>xxxx</p><video>...</video>

   <noahm> <p>xxxx</p><video>...</video>

   <noahm> <p>xxxx<video>...</video>

   <noahm> <html><body> <p>xxxx<video>...</video></body></html>

   propose we endorse
   [24]http://lists.w3.org/Archives/Public/public-html/2007Aug/1188.htm
   l

     [24] http://lists.w3.org/Archives/Public/public-html/2007Aug/1188.html

   ([25]http://dev.w3.org/html5/spec/infrastructure.html#conformance-re
   quirements )

     [25] http://dev.w3.org/html5/spec/infrastructure.html#conformance-requirements

   <ht>
   [26]http://www.whatwg.org/specs/web-apps/current-work/#conformance-r
   equirements

     [26] http://www.whatwg.org/specs/web-apps/current-work/#conformance-requirements

   "XML documents that use elements or attributes from the HTML
   namespace and that are served over the wire (e.g. by HTTP) must be
   sent using an XML MIME type such as application/xml or
   application/xhtml+xml and must not be served as text/html.
   [RFC3023]"

   <noahm> Doesn't that rule out <p>XXXXX</p> as text/html

   yes

   PROPSED: take out ^^^

   RESOLUTION: to request that "XML documents that use elements or
   attributes from the HTML namespace and that are served over the wire
   (e.g. by HTTP) must be sent using an XML MIME type such as
   application/xml or application/xhtml+xml and must not be served as
   text/html. [RFC3023]" be removed

   LMM: there's also the overall compatibility stuff...
   ... but perhaps we can follow that up in a different vendue

Discussion topics with HTML WG on Thursday: data

   TBL: PROPOSED: that the microdata [data?] section be removed

   HT: I gather the microdata stuff is specified separately, while it's
   still in the spec

   <masinter> there is something else we might also want to say about
   text/html, even if we aren't ready to say

   TBL: PROPOSED: that the microdata section be moved to a separate
   spec
   ... PROPOSED2: that the data-* section be moved to a separate spec

   LMM: no... they should be removed, not just moved; they're out of
   scope of the WG
   ... the proponents are free to propose it, and to ask that the WG
   charter be extended...

   TVR: given that the WHATWG has declared last call and that they've
   published an aggregate spec, it seems likely that if they remove it
   from the W3C spec, they'd keep it in the WHATWG spec

   TBL: yes, that won't surprise me...

   LMM: vendors often implement and specify non-standard stuff
   ... a rats-nest of overly interdependent stuff stifles innovation

   NM: I wonder which version of the spec would get pointed to from the
   media type registration

   <masinter> The requirement for the charter of HTML WG is that it
   should have extensibility mechanisms that would allow it

   <ht> [27]the separate Microdata draft (it's 3 months old)

     [27] http://html5.digitalbazaar.com/specs/microdata.html

   <ht> Not clear what status it has -- it's _not_ at WhatWG. . .

   timbl: we should not be distracted by what WhatWG may or may not do

   <ht> [28]HTML WG Microdata/RDFa issue

     [28] http://www.w3.org/html/wg/tracker/issues/76

   yes, we just took a position on issue 76 (microdata)

   RESOLUTION: to request that the microdata section be removed from
   the HTML 5 spec

   RESOLUTION: to request that the data-* section be removed from the
   HTML 5 spec

   <ht> [29]bug 7542 "Remove Section 5. Microdata"

     [29] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7542

Discussion topics with HTML WG on Thursday: authoring spec

   NM: about the idea of an "authoring spec" for HTML 5...
   ... we talked about that in Maneliue [sp?]
   ... IH said he could produce that as a view of the text he wrote
   ... I had some misgivings that this would work, but he has since
   done it...
   ... I tried to grab it and read it on the plane but found that I
   only got the TOC document

   author view of HTML 5 spec - static copy (2nd try) Dan Connolly
   (Wednesday, 26 August)
   [30]http://lists.w3.org/Archives/Public/public-html/2009Aug/1296.htm
   l

     [30] http://lists.w3.org/Archives/Public/public-html/2009Aug/1296.html

   scribe: I'm interested to take a closer look in the next couple
   days... can anybody tell me how the WG treats it?

   DanC: I did some scripting with it a while back...
   ... what I like most about it is that it clarifies discussion with
   the editor; you can ask "is this about browsers or about documents"
   and see the outcome clearly in the spec

   LMM: I don't think many of the API invariants are document
   [clearly?] [?]

   TVR: I don't find this "view of the big spec" approach appealling.
   It doesn't tell producers the minimum they need to do to conform [?]

   NM: LMM, there is a lot about DOM APIs in the authoring version of
   the spec

   <noahm> [31]http://dev.w3.org/html5/spec-author-view/spec.html

     [31] http://dev.w3.org/html5/spec-author-view/spec.html

   LMM: I spent a lot of energy on one example: downloading images,
   width and "available" and "not available"

   <timbl> TVR: The original spec was said to be necessarily
   non-machine readable, and this new auhtoring spec is said to be a
   CSS-filtere version of the original, and theefore a spec which is
   also not machine-readable, and therefore -- as I beleive a language
   should be specs in a machne-readble way -- not a suitable spec. (?)

   <ht> Where did that link _come_ from??????

   TVR: so how is this image width analysis relevant to the authoring
   spec?

   LMM: it's specified as a normative algorithm. what it tells authors
   is that if width is available, height is available. [er... I thought
   he was going to point out a problem but I didn't hear him give one;
   did he get cut off?]
   ... my point, and it applies to other API specs as well, is that the
   HTML 5 spec doesn't give a reasonable [... SCRIBE BRAIN EXPLODING]

   NM: my point is that this "view of the main spec" won't produce
   something good for authors

   HT: whether a spec should be for implementors or end-users is a very
   interesting question with lots of history in W3C, but it's
   editorial, and not architectural

   LMM: a language spec serves not only authors and browser
   implementors but lots of other sorts of agents that consume/produce
   HTML.

   <ht> Lachlan Hunt's "A Web Developer’s Guide to HTML 5" has
   sometimes been referred to as an authoring guide:
   [32]http://dev.w3.org/html5/html-author/

     [32] http://dev.w3.org/html5/html-author/

   <ht> THis is the WG's issue on this topic:
   [33]http://www.w3.org/html/wg/tracker/issues/59

     [33] http://www.w3.org/html/wg/tracker/issues/59

   <ht> Here's Mike Smith's document:
   [34]http://dev.w3.org/html5/markup/

     [34] http://dev.w3.org/html5/markup/

   <ht> Here's an interesting survey of the authoring spec. space:
   [35]http://edward.oconnor.cx/2009/09/normativity
   .
   .

     [35] http://edward.oconnor.cx/2009/09/normativity

Disucssion with HTML WG chairs

   +PaulC

   +SamR

   [discussion of logistics for Thu... 1pm start time suggested.]

   NM: tell us about last call... where are you?

   SR: we're trying to get issues raised ASAP, rather than having the
   community treat last call as a time to start raising issues

   PC: we're setting up a last call process

   NM: we just noted/discussed the bug/tracker-issue escalation stuff

   PC: we've been testing the last call process in the WG
   ... the accessibility issues look like a long pole get over

   SR: e.g. there's an accessibility issue where a _proposal_ is due 17
   Dec
   ... we're setting expectation that lacking a propsal, we'll time-out
   issues

   NM: are these internal issues? do you check with issue raisers?

   SR: it's such an open WG, but yes, in some sense they're all
   internal so far
   ... [..missed some...] "canvas isn't accessible" is both hard and
   [wrong?].

   HT: can you clarify... are issues closed simply for lack of a
   proposal?

   PC: we close _without prejudice_, so they can be re-opened at a
   later stage if required, and we explicitly call for consensus

   [discussion of polyglot documents...]

   [discussion of text/html media type registration... whether it
   should go in the html 5 spec or not... to what extent the html 5
   spec re-writes history]

   (ht which is that issue again?)

   <ht> [36]http://www.w3.org/html/wg/tracker/issues/76

     [36] http://www.w3.org/html/wg/tracker/issues/76

   [missed some...]

   PC: advocates of microdata/RDFa haven't said they think they should
   be developed independently of the HTML WG.

   HT: it's people outside the WG that express this opinion

   LMM: yes, the W3C membership explicitly considers these modularity
   issues, as they relate to which experts/engineers to send to which
   groups

   SR: hmm... not sure I'd heard concerns around data-* before

   PC: right; don't expect the WG to be familiar with that.

   TBL: data-* competes with URI-based designs such as RDFa

   SR: odd... data-* is local to a page... i.e. to be consumed by js on
   the page, not by crawlers

   TBL: but once there's lots of useful data-* data somewhere, crawlers
   will want to crawl

   SR: hmm... yes, I can see the inevitability of that. hmm.

   [... discussion of various lists of things in various stages of
   discussion]

   NM: we didn't get to distributed extensibility this AM

   SR: there are 2 things: (1) do we want people to be able to make up
   their own elements? (2) XML namespaces as is. Don't lead with (1) if
   your requirement is actually (2)

   NM projects quote from HTML 5 spec on
   #other-applicable-specification

   [discussion of the CSS moz- technique in comparison to URI-based
   techniques]

   <ht> yes

   [discussion of DOMs with namespaces that can only be created from
   scripts, not from markup]

Summary of Action Items

   [End of minutes]
     _________________________________________________________


    Minutes formatted by David Booth's [37]scribe.perl version 1.135
    ([38]CVS log)
    $Date: 2009/11/17 15:52:18 $

     [37] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [38] http://dev.w3.org/cvsweb/2002/scribe/


[1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

        TAG meeting during Santa Clara TPAC, part 2 (Friday AM)

06 Nov 2009

Attendees

   Present
          Noah_Mendelsohn_(NM), Henry_Thompson_(HT),
          Larry_Masinter_(LMM), Ashok_Malhotra_(AM), Dan_Connolly_(DC),
          Tim_Berners-Lee_(TBL)

   Regrets
          John_Kemp, Jonathan_Rees, TV_Raman

   Chair
          Noah

   Scribe
          timbl

Contents

     * [2]Topics
         1. [3]Security BOF out-brief
         2. [4]HTML joint session debrief
         3. [5]Decentralized extensibility debate review
         4. [6]EXI WG requests review of a content coding
         5. [7]Dec f2f planning
         6. [8]URI Packaging
         7. [9]IRI BOF Report
         8. [10]Default XML Processing Model - 10 min heads-up [Henry]
         9. [11]TAG telecons, Noah's conflict
     * [12]Summary of Action Items
     _________________________________________________________

   <DanC> Date: 6 Nov 2009

Security BOF out-brief

   <scribe> scribenick: timbl

   <DanC> [13]http://esw.w3.org/topic/TPAC_Security_BOF

     [13] http://esw.w3.org/topic/TPAC_Security_BOF

   [Instituting more of a policy of protocol review of W3C activities.
   ]

   Noah: How is W3C organized to deal with security?

   DanC: T&S domain tends to specialize in security. There was a Web
   Security Context (WSC) working group which did the browser chrome
   thing. There is no generic horizontal security activity [like acc'y
   or I18n].

   Noah: So the TAG is the only general group looking
   cross-wg..frightening

   LM: Security is not a a specialty of the TAG. The IETF has a
   Security directorate, and every document has a threat analysis and
   mitigation review.

   DanC: a new mailing list and/or wiki maybe coming out of the lunch
   security BOF.

   LMM: Some people thought the overhead of IG would be too big. But f
   there were such a group, then there would be many people from member
   companies who would participate. I suggest we the TAG endorse this.

   <masinter> ... and encourage W3C staff to pursue this because the
   TAG isn't prepared to do the security architectural work that needs
   to be done.

   <DanC> +0 on endorse...; it sounds well and good, but ...

   Ashok: Security on the web, or device security too?

   LMM: Wherever W3C does work.

   <Zakim> noahm, you wanted to noodle on security entry in Web apps
   "Table of Contents"

   Noah: Two things one of which is yes i think it would be good for us
   to agree that we should help people [lost]
   ... we could find a tag member who could spend some time thinking
   about this. I hear l Larry say security is important, and we should
   say security is something that w3c should do better, but he didn't
   say that the tag should offer, yes if you want is to we will tell
   you what you think of your security issue.

   <DanC> action-306?

   <trackbot> ACTION-306 -- Larry Masinter to work with JK and AM to
   update Web Application architecture outline based on discussions at
   TAG meetings -- due 2009-10-31 -- OPEN

   <trackbot> [14]http://www.w3.org/2001/tag/group/track/actions/306

     [14] http://www.w3.org/2001/tag/group/track/actions/306

   DanC: CORS and Origin Header .. seem close to security

   Larry: Suggest we ask Thomas to report

   ACTION DanC as Thomas for a report form the security BOF

   <trackbot> Created ACTION-323 - As Thomas for a report form the
   security BOF [on Dan Connolly - due 2009-11-13].

   <DanC> ACTION: DanC to invite Thomas to report on actions from TPAC
   security BOF

   <trackbot> Created ACTION-324 - Invite Thomas to report on actions
   from TPAC security BOF [on Dan Connolly - due 2009-11-13].

   <ht> From Mike Smith, authored (?) by Anne van K., minutes from the
   security BOF: [15]http://www.w3.org/2009/11/05-security-minutes.html

     [15] http://www.w3.org/2009/11/05-security-minutes.html

   Noah: In December I want to crank up our focus on Metadata.

   Ashok: We are stalled .. how should we move this forward. Thinking
   about device APIs ...

   Noah: Broader than that .. a full road map of web applications,
   including security.

   [discussion of pressure of work and scheduling]

   Noah: We meet on December 1. Let us review it before, November 19?

   <DanC> action-306 due 1 Dec

   <trackbot> ACTION-306 Work with JK and AM to update Web Application
   architecture outline based on discussions at TAG meetings due date
   now 1 Dec

   Larry and Ashok will meet Nov 17 18 and the TAG will get it on 1st
   and discuss it on the face-face on the 6th

HTML joint session debrief

   HT: As there was agreement about the substantive point, we didn't
   need maybe to spend 45 minutes discussing the polyglot issue, but in
   fact I think it was useful.

   Noah: We went though the agenda we brought with us and got though
   most of it.

   HT: I found it interesting that many influential member of the HTML5
   WG seem to have very little awareness of the document and content
   management industry, which has largely switched to end-to-end XML
   over the last few years.

   Timbl: Some people in the HTML group committed to do their best to
   expand the polyglot overlap to be as big as possible. I applauded
   that move, as the polyglot language is really valuable. Noted that
   Kai/Deutche Telecom pointed out that his whole site was polyglot.

   <masinter> Polyglot documents are *not* defined in the document, and
   so the commitment to make sure they are allowed in the document is
   insufficient.

   <DanC> it was news to me that Karl had written something about
   "versatile" documents (aka polyglot documents)

   Timbl: It was pointed out that there was a large XML-using community
   who have web pages and want them to be XML.

   <DanC> [16]whatwg notes on polyglot docs

     [16] http://wiki.whatwg.org/wiki/HTML_vs._XHTML

   <timbl_> That's it

   <DanC> note also "First Polyglot Validator Check Deployed"
   [17]http://intertwingly.net/blog/2009/09/08/First-Polyglot-Validator
   -Check-Deployed

     [17] http://intertwingly.net/blog/2009/09/08/First-Polyglot-Validator-Check-Deployed

   <masinter> The text/html MIME type should reference the description
   of polyglot documents which is currently not in the text/html MIME
   type registration

   HT: I noted in corridor discussion that if you are using digital
   signature with your XML documents, converting them to HTML syntax
   for transmission is not an option.

   DanC: I think the community has evolved its understanding of what is
   acceptable.

   <DanC> DanC: two things: (a) whether formerly valid stuff is now
   invalid and (b) whether history is preserved; I think (a) is
   acceptable and hixie claimed history section of HTML 5 subsumes the
   history in the RFC. so if they don't change anything, I'm satisfied.

   Larry: The place where the the IANA considerations for MIME type
   registration, section 31.1 ..

   [discussion of section 13.1]

   Larry: This doesn't say that the previous document types under
   earlier versions of HTML are allowed too.
   ... RFC2854, under 'published specifications' it explained it.

   Noah: In practice the goal of the spec is to include the older
   languages

   Larry: I don't believe that the HTML5 document does currently
   clearly define a language which includes all others

   DanC: Specifically, an example if that the @profile attribute has
   been removed, when it was in HTML4.

   <ht> Combining "This document is the relevant specification.
   Labeling a resource with the text/html type asserts that the
   resource is an HTML document using the HTML syntax." with "XML
   documents that use elements or attributes from the HTML namespace
   and that are served over the wire (e.g. by HTTP) must be sent using
   an XML MIME type such as application/xml or application/xhtml+xml
   and must not be served as text/html. [RFC3023]" we don't have a
   satisfactory state. If the

   HT: This [above] is what Hixie promised to change, until it is
   changed we can't evaluate the result.

   <scribe> ACTION: HT to Assign himself an action to track the text
   """urce with the text/html type asserts that the resource is an HTML
   document using the HTML syntax." with "XML documents that use
   elements or attributes from the HTML namespace and that are served
   over the wire (e.g. by HTTP) must be sent using an XML MIME type
   such as application/xml or application/xhtml+xml and must not be
   served as text/html. [RFC3023]" we don't have a satisfactory state.
   If the"""

   <trackbot> Created ACTION-325 - Assign himself an action to track
   the text """urce with the text/html type asserts that the resource
   is an HTML document using the HTML syntax." with "XML documents that
   use elements or attributes from the HTML namespace and that are
   served over the wire (e.g. by HTTP) must be sent using an XML MIME
   type such as application/xml or application/xhtml+xml and must not
   be served as text/html. [RFC3023]" we don't have a satisfactory
   state.

   <DanC> (Henry, I'm not sure there's a bug on the media type stuff;
   the/a bug Sam opened right away was w.r.t. web addresses)

   <ht> I found it, its
   [18]http://www.w3.org/Bugs/Public/show_bug.cgi?id=8154

     [18] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8154

   <ht> ACTION Henry S to track HTML WG progress on their bug 8154 on
   polyglot documents, due 2009-12-05

   <trackbot> Created ACTION-326 - S to track HTML WG progress on their
   bug 8154 on polyglot documents, due 2009-12-05 [on Henry S. Thompson
   - due 2009-11-13].

   LMM: I think the microdata stuff should be not only factored out but
   removed as out of HTML WG charter scope; to pursue it involves a
   charter change or a new WG

   TimBL: Lets as a the TAG file a bug in real time now requesting the
   removal of the the Microdata section, and remove it (with no
   normative reference).

   Because ... [collecting rationale in IRC...]

   <noahm> Modularity is beneficial in this case. There are alternative
   technologies such as RDFa, and separating specs for metadata is a
   good thing.

   <DanC> RDFa is in considerable and increasing deployment (before
   saying it's a REC)

   - The modularity of the document is damaged. The issue of putting
   data into HTML5 documents is sufficiently separate functionality
   that it would be better to have a separate document which people
   interested in data can review without having to read the rest of the
   space.

   <masinter> Metadata architecture is complex; real world widely
   deployed metadata management systems have found that distributed
   extensibility is even more important for metadata than for markup,
   since each organization and community has different desires for
   metainformation even if they share common understanding of the data.

   <noahm> the modularity of both the design and the documentation of
   it is damaged

   - The microformat bits in fact overlap with, and would need review
   by , dramatically separate communities such as calendaring
   (iCalendar etc), contact (vCard etc).

   <Zakim> DanC, you wanted to consider endorsement of
   [19]http://lists.w3.org/Archives/Public/public-html/2009Oct/0773.htm
   l

     [19] http://lists.w3.org/Archives/Public/public-html/2009Oct/0773.html

   <masinter> The embedding of this specification within HTML5 hinders
   the involvement to the web content management community.

   [20]http://www.w3.org/html/wg/tracker/issues/76

     [20] http://www.w3.org/html/wg/tracker/issues/76

   [discussion of fine tuning of the bug]

   RESOLUTION: To endorse
   [21]http://www.w3.org/html/wg/tracker/issues/76 and file a bug for
   removal of the Microdata section form HTML4.

     [21] http://www.w3.org/html/wg/tracker/issues/76

   <ht> The HTML Bugzilla bug for "remove microdata" filed by the TAG
   is [22]http://www.w3.org/Bugs/Public/show_bug.cgi?id=8220

     [22] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8220

Decentralized extensibility debate review

   HT: This felt awkward to me from the podium
   ... But I hear it seemed to go well.
   ... I have a better sense of where people who oppose NSs think the
   costs are.
   ... That is, the cost of the tuple representation of names at the
   API level; and also the syntactic overhead of managing them, and
   vulnerability from lexical scoping when you are cutting and pasting.

   <DanC> (re tuples as names, the XML community is hoisted by its own
   petard in that case; if they'd just combined them into one URI, this
   wouldn't be a problem.)

   HT: The other issue, with a different character, raised by Larry,
   was about where you buy into the "decentralized" part at all. There
   was actually much less of the Henri's "We have done all the
   extensibility we need" position.
   ... Going forward, we have a much better sense of how to frame
   arguments.

   Larry: Either the costs reduced or the benefits outweigh them.

   TimBL: Meanwhile these "Unobtrusive Namespace proposals"

   <masinter>
   [23]http://lists.xml.org/archives/xml-dev/200909/msg00068.html

     [23] http://lists.xml.org/archives/xml-dev/200909/msg00068.html

   DanC: That doesn't do anything for me

   HT: MY reading is that:
   ... there are two classes of proposal:

   <DanC> (Liams's proposal with outboard namespace declarations
   doesn't meet the
   [24]http://www.w3.org/TR/NOTE-webarch-extlang#Ambiguity requirement,
   aka lexical scoping)

     [24] http://www.w3.org/TR/NOTE-webarch-extlang#Ambiguity

   HT: 1) Liam's for example is to make it easier to change the default
   ns withing certain scopes. There is an out-of-band description of
   how to do this, but in well known situation they can be hard-coded,
   like HTML.
   ... 2) Or there is an appeal to out-of-band information, which is
   used to set up non-default prefixes, like SVG: "Media type derived
   namespace declarations".

   TimBL: These all follow from the media type.

   HT: ... I prefer (2)

   <Zakim> noahm, you wanted to talk about Liam's proposal

   <DanC> (perhaps I read a version of Liam's proposal that's so old
   that it doesn't bear on this discussion; pointer to modern version,
   please?)

   Noah: What I like about Liam's is that it gives you NS and also
   allows you to evolve a tag from an experimental namespace into a new
   version of a well-known namespace.
   ... (BTW Liam had sent his idea to the Hypertext Coordination group,
   which had not been an effective place, but now it is sent t the HTML
   WG)

   <ht>
   [25]http://www.balisage.net/Proceedings/vol3/html/Quin01/BalisageVol
   3-Quin01.html

     [25] http://www.balisage.net/Proceedings/vol3/html/Quin01/BalisageVol3-Quin01.html

   HT: Option 2 has never been really written down.
   ... That ^^ was a version of Liam's proposal.

   DanC: The current HTML5 spec is an example of one of these.

   Larry: Henry, Could you submit a bug to the HTML WG that you would
   like this?

   HT: First I need to read Tony Ross's proposal. (linked from the
   agenda or from noah's talk which is)

   <DanC> further discussion showed that Dan had a different "these" in
   mind and the HTML 5 spec isn't an instance.

   <ht> ACTION Henry to review Microsoft's namespaces in HTML 5
   proposal

   <trackbot> Created ACTION-327 - Review Microsoft's namespaces in
   HTML 5 proposal [on Henry S. Thompson - due 2009-11-13].

EXI WG requests review of a content coding

   DC: Tim, do you believe their use cases cover any of the interesting
   cases?

   Tim: yes, e.g., they demonstrated on a very large SVG file;
   demonstration was that it loads 200 times faster

   Noah: We we not sure of the original speed analysis of these but I
   don't think we have any issues now

   [agreed generally, so we move on]

   Noah: We asked them to register a content-encoding value and they
   have, so we should thank them.

   HT: We were worried that, because the encoding actually is lossy in
   that that the double quotes on attributes become single quotes, it
   wouldn't be accepted by the IESG, but it was.

   <noahm> Proposal: the TAG thanks the EXI working group for
   registering the exi content-coding. Your registration completely
   resolves the concern we expressed in Mandelieu

   PROPOSED: We thank the EXI WG for registering the content encoding
   and encourage them in their endeavors.

   <noahm> Either is fine with me.

   <DanC> "exi" is registered; I don't know whether it's case sensitive

   <noahm> I note that this >is< what we encouraged them to do.

   TimBL: Oh dear, another nail in the coffin of the plot to use double
   quotes for all attribute values except single quotes when it is a
   qname ;-)

   <DanC> (if the rationale is "this is what we asked them to do" then
   I need a pointer)

   RESOLUTION: We thank the EXI WG for registering the content encoding
   and encourage them in their endeavors.

   <DanC> for reference, exi registration request
   [26]http://www.alvestrand.no/pipermail/ietf-types/2008-October/00210
   3.html

     [26] http://www.alvestrand.no/pipermail/ietf-types/2008-October/002103.html

   ACTION Noah convey to the EXIWG the resolution "We thank the EXI WG
   for registering the content encoding and encourage them in their
   endeavors.".

   <trackbot> Created ACTION-328 - Convey to the EXIWG the resolution
   "We thank the EXI WG for registering the content encoding and
   encourage them in their endeavors.". [on Noah Mendelsohn - due
   2009-11-13].

Dec f2f planning

   NM: seems we should do webapps architecture at our Dec f2f meeting

   <DanC> (TOC, for ref
   [27]http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921 )

     [27] http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921

   NM: Raman will not be there at the Dec f2f meeting

   <masinter> scribenick: masinter

   <noahm> Ashok will help Raman frame the F2F agenda and preparation
   on Web Application Architecture

   [postscript: see ACTION-306 and ACTION-337]

   <noahm> Ashok will frame the F2F agenda and preparation on metadata
   access

   [postscript: see ACTION-336]

   <noahm> :Larry will frame the F2F agenda and preparation on metadata
   formats/representations

   [postscript: see ACTION-337]

   <DanC> action-321?

   <trackbot> ACTION-321 -- Larry Masinter to lightly edit TAG input to
   DAP WG per 8 Oct and tell Noah -- due 2009-10-29 -- OPEN

   <trackbot> [28]http://www.w3.org/2001/tag/group/track/actions/321

     [28] http://www.w3.org/2001/tag/group/track/actions/321

   <DanC> action-321 due next week

   <trackbot> ACTION-321 lightly edit TAG input to DAP WG per 8 Oct and
   tell Noah due date now next week

   <noahm> ACTION: Noah to schedule F2F of Henry's work on referencing
   changing specs

   <trackbot> Created ACTION-329 - Schedule F2F of Henry's work on
   referencing changing specs [on Noah Mendelsohn - due 2009-11-13].

   <noahm> Dan volunteers best effort to do early versions of the
   agenda for F2F.

   <noahm> Noah thanks him >profusely<

   <DanC> ACTION: DanC to prepare Dec f2f agenda in collaboration with
   Noah etc.

   <trackbot> Created ACTION-330 - Prepare Dec f2f agenda in
   collaboration with Noah etc. [on Dan Connolly - due 2009-11-13].

   Noah: Unfortunately, we didn't get to on stage called for
   nominations to the W3C TAG.

URI Packaging

   <DanC> scribenick: DanC

   LM: I reviewed widget:
   ... reported to webapps widget subgroup...
   ... reviewed it from the p.o.v. of an author of IETF guidelines on
   making new URIs
   ... i.e. not exactly a TAG review or Adobe review
   ... I'm surprised that the WG considered it done
   ... e.g. several things "out of scope" but URI registration
   guidelines requires that things be well-defined; "out of scope"
   isn't well-defined

   LMM's review

   LMM's review:
   [29]http://lists.w3.org/Archives/Public/www-tag/2009Oct/0010.html

     [29] http://lists.w3.org/Archives/Public/www-tag/2009Oct/0010.html

   [[ AWWW Suggestion: add guideline: "Make New URI Schemes Reusable If
   You Can't Reuse URI schemes".

   ]

   ]

   LMM: perhaps thismessage: could have been extended, rather than
   making a new URI scheme.
   ... it's from MIME multipart
   ... for references between MIME parts

   <timbl> ... The thismessage: URI scheme is a neat URI scheme which
   does actually work and i widely deployed

   [30]http://www.rfc-editor.org/rfc/rfc2557.txt <-
   [31]http://www.iana.org/assignments/uri-schemes.html

     [30] http://www.rfc-editor.org/rfc/rfc2557.txt
     [31] http://www.iana.org/assignments/uri-schemes.html

   <timbl> ... You can make relative URIs but they don't resolve to
   anything except relative the message.

   <timbl> ... If you have message within message then you flatten it.

   TBL: yes, that AWWW suggestion appeals to me.

   <timbl> LMM: I suggest in my review adding to AWWW the advice "i you
   can't reuse another r scheme, and then if you can, make you new
   scheme re-=usable".

   HT: thinking about the impact on implementers...

   <timbl> Tim: The document should have real-life examples.

   HT: old implementations of the extended scheme won't necessarily be
   updated

   <timbl> Noah: We would normally start with a finding for this sort
   of thing.

   <scribe> scribe: timbl

   LMM: The draft charter for IRI is to update the guidelines for new
   URI schemes.
   ... I withdraw the suggestion.

   <noahm> q

IRI BOF Report

   LMM: ... I met with the I18n group on Tuesday, and had dinner last
   night with 14 people discussing IRIs, in the unicode consortium,
   Lisa Dusseault (sp?) , Mike Smith
   ... Mike was to represent the HTML5 contingent in this.

   <DanC> (note to self... brief MikeSmith on HTML 5 URI design
   details... maybe I'll action myself... noah, do you mind?)

   <masinter>
   [32]http://trac.tools.ietf.org/area/app/trac/wiki/DraftIriCharter

     [32] http://trac.tools.ietf.org/area/app/trac/wiki/DraftIriCharter

   LMM: It looks very positive for agreement hat there should be a WG
   in the IETF wit aggressive time schedule,
   ... with that [linked] as draft charter.

   DanC: Any chair candidates?

   LMM: Maybe

   <masinter> volunteers to help with chairing, managing the issue
   list, shepherding the various working groups involved

   LMM: I count 9 committees who are interested in what IRIs are. They
   are listed at the end of the charter.
   ... I added ICANN.
   ... This is the one committee to rule them all and in the darkness
   bind them.

   <masinter> [33]http://tools.ietf.org/html/draft-duerst-iri-bis-07

     [33] http://tools.ietf.org/html/draft-duerst-iri-bis-07

   LMM: Right now, what web browsers will accept in a href="here"
   cannot be put in other service which take URIs. There is a specified
   mapping in the document which was posted, in a new versions of the
   IRI-bis document, which ... [lost]
   ... This IRI-bis document defines in section 7 a processing model to
   handle otherwise invalid IRIS which will make an IRI out of any
   string.
   ... In the definitions, in section 1.3,
   ... It defines LEIRI and Web-ADDRESS as strings which might
   otherwise survive such processing.
   ... : ... section 7.2 ...
   ... One needs to find a better name/abbreviation for these ..

   HT: This works for me

   LMM: This is my cut at the knot.

   <DanC> (the word "survive" isn't in the document... ah...
   "acceptable input to the processing rules in Section 7.2.")

   <DanC> ACTION-298?

   <trackbot> ACTION-298 -- Larry Masinter to notify the TAG of the
   next IRI draft -- due 2009-09-16 -- PENDINGREVIEW

   <trackbot> [34]http://www.w3.org/2001/tag/group/track/actions/298

     [34] http://www.w3.org/2001/tag/group/track/actions/298

   TimBL: Can you remove the // while you are at it? ;-)

   <DanC> close action-298

   <trackbot> ACTION-298 Notify the TAG of the next IRI draft closed

   <ht> Here's the HTML WG Issue for web addresses:
   [35]http://www.w3.org/Bugs/Public/show_bug.cgi?id=8207

     [35] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8207

   <DanC> (our iriEverywhere issue is now open with no actions, which
   bothers the pedant in me, but I can't think of... ah... NM is
   pursuing it.)

   <DanC> close item 7

   HT:

   <DanC> close item 10

Default XML Processing Model - 10 min heads-up [Henry]

   HT: At the Director's insistence, when the XML proc model was
   chartered, it was chartered to do two things, what ht group wanted
   to do, which was a new scripting language, and what the Director
   [and DanC] wanted as well which was to define the default processing
   model of an XML document.
   ... HT: I decided eventually there was very little one could say
   about the default processing mdoel... and Norm Walsh and I wrote it
   on he back of a napkin yesterday.

   <masinter> danc, iriEverywhere -- suggest we ask W3C I18N to produce
   Rec which points people at IRI and updates
   [36]http://www.w3.org/TR/charmod-resid/ and LEIRI etc.

     [36] http://www.w3.org/TR/charmod-resid/

   HT: This is space whcih ther spcs can be iused to explain what the
   input to t epropcess is. It does Xinclde,. It says you must process
   the external subset. It saif you muse updat ethabse URI of
   documents, and annotae al; XML ID elements with ID specs. So there
   is just one consequent of any incoming XML document.
   ... That is consequent as a n infoset.

   TimBL What about decryption?

   <ht> [37]http://www.w3.org/XML/XProc/docs/defproc.html

     [37] http://www.w3.org/XML/XProc/docs/defproc.html

   <DanC> issue-34?

   <trackbot> ISSUE-34 -- XML Transformation and composability (e.g.,
   XSLT,XInclude, Encryption) -- OPEN

   <trackbot> [38]http://www.w3.org/2001/tag/group/track/issues/34

     [38] http://www.w3.org/2001/tag/group/track/issues/34

   <DanC> action-239?

   <trackbot> ACTION-239 -- Henry S. Thompson to alert chair when
   updates to description of xmlFunctions-34 are ready for review (or
   if none made) -- due 2009-12-01 -- OPEN

   <trackbot> [39]http://www.w3.org/2001/tag/group/track/actions/239

     [39] http://www.w3.org/2001/tag/group/track/actions/239

   HT: This resolves a 10 -year old ambiguity that there is not one
   defined infoset associated with any doument.
   ... YOu don't ahev to use it.

   TimBL: Then how doe sthe receiver know whether to?

   <DanC> DanC: "default" is a misnomer, then

   <DanC> HT: I can see that.

   LMM: Chris LIlley reminds me that there was going to na an update
   teo the application/xml and so the default processing model could be
   mentioned here.

   Noah: What about the Follow Your Nose question? How to get to teh
   set of specs from the document you receive? This dooesn't seem to
   solve that problem.

   <Zakim> noahm, you wanted to say this goes half way

   LMM: You could urge a spec writer to define the rpocessingmodel from
   the MIME spec.

   Noah: This best practice for xml applications ike purcase orders
   they do this.

   <DanC> (the best way to say that this isn't _the_ only one is to
   document 2. I think the "what you see is what you get" processing
   model should get at least equal, if not preferred, footing. i.e. no
   external anything)

TAG telecons, Noah's conflict

   Noah: We wil lhave teleconferences in the 12 and 19th. Regrets from
   Noah for the

   12th

   ADJOURNED

   <DanC> taking a look at
   [40]http://www.w3.org/2001/tag/group/track/agenda ... organizing
   actions by issue/product...

     [40] http://www.w3.org/2001/tag/group/track/agenda

Summary of Action Items

   [NEW] ACTION: DanC to invite Thomas to report on actions from TPAC
   security BOF
   [NEW] ACTION: DanC to prepare Dec f2f agenda in collaboration with
   Noah etc.
   [NEW] ACTION: HT to Assign himself an action to track the text
   """urce with the text/html type asserts that the resource is an HTML
   document using the HTML syntax." with "XML documents that use
   elements or attributes from the HTML namespace and that are served
   over the wire (e.g. by HTTP) must be sent using an XML MIME type
   such as application/xml or application/xhtml+xml and must not be
   served as text/html. [RFC3023]" we don't have a satisfactory state.
   If the"""
   [NEW] ACTION: Noah to schedule F2F of Henry's work on referencing
   changing specs

   [End of minutes]
     _________________________________________________________


    Minutes formatted by David Booth's [41]scribe.perl version 1.135
    ([42]CVS log)
    $Date: 2009/11/17 16:48:05 $

     [41] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [42] http://dev.w3.org/cvsweb/2002/scribe/



-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Thursday, 19 November 2009 17:03:38 UTC