Nabble - w3.org - public-tag-announce

minutes TAG meeting Nov 2, 6 in Santa Clara

2009-11-19T09:03:31Z

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

Minutes of 23-25 Sept 2009 TAG F2F now available

2009-10-16T13:36:12Z

Unapproved draft minutes from the F2F meeting held by the TAG from Sept.
23-25 2009 are now available. Links to records of individual discussions
are available from an updated copy of the agenda page [1], and for most
readers these will be the easiest way to find items of interests. The
agenda links are into the complete records for the respective days [2-4].
Text-only copies of the minutes are also appended to this email. I expect
that the TAG will consider approving these as a true record during our
teleconference on 22 October. Thank you.

Noah

[1] http://www.w3.org/2001/tag/2009/09/23-agenda
[2] http://www.w3.org/2001/tag/2009/09/23-minutes
[3] http://www.w3.org/2001/tag/2009/09/24-minutes
[4] http://www.w3.org/2001/tag/2009/09/25-minutes

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

[1]W3C

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

- DRAFT -

TAG Sep 2009 meeting in Cambridge, MA

23 Sep 2009

[2]Agenda

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

See also: [3]IRC log

[3] http://www.w3.org/2009/09/23-tagmem-irc

Attendees

Present
DanC, TimBL, ht, jar, jkemp, lmm, noahm, Ashok

Regrets
TVR

Chair
Noah Mendelsohn

Scribe
John Kemp, Larry Masinter

Contents

* [4]Topics
1. [5]Convene, Review Agenda
2. [6]HTML, collecting issues
3. [7]references to versioned specifications (HTML 5 review
topic #15)
4. [8]Architecture of Web Applications
5. [9]HTML issue collection, cont
6. [10]document conformance vs. user agent conformance
requirements (#13)
7. [11]discussion of work on webapis
8. [12]wrap up for the day (agenda review)
* [13]Summary of Action Items
_________________________________________________________

Convene, Review Agenda

<jkemp> scribe: John Kemp

<jkemp> scribenick: jkemp

nm: (reviews "review goals" + agenda)
... discuss HTML5, and what (if any) feedback we want to give to WG
... review and make progress on items agreed at last F2F
... discuss TPAC logistics
... TPAC program committee wants to organize a session on
"decentralized extensibility" and has asked me for help in framing
the session
... not limited to the sessions and goals listed

ht: would like to keep slot on naming

lmm: would like to talk about IRIs

nm: (review each slot)

HTML, collecting issues

nm: notes the relatively new HTML 5 "authoring specification"

nm solicits HTML 5 spec issues to discuss; builds a list:
[14]http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt

[14] http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt

lmm: redefinition of text/html MIME type is one issue - would help
to have common understanding on use of MIME types
... issue of error handling came up in a specific URI parsing case
... a lot of these error handling questions reduce to "what is the
role of a standard or specification"?

tbl: you want to discuss whether the error handling is defined in
the specification?

lmm: (roughly) yes

<masinter> how it is defined

nm: reviews JK issues
[15]http://lists.w3.org/Archives/Public/www-tag/2009Sep/0012.html

[15] http://lists.w3.org/Archives/Public/www-tag/2009Sep/0012.html

jar: HTML5 has some innovations in how the specification has been
developed
... to what affect does W3C want to carry through some of these?

nm: and use use-cases to illustrate where particular innovations
work and don't work

lmm: problem that arises when normative algorithm is used to give
constraints
... instead of giving invariants which would be exhibited by
applying an (or different) algorithm(s)

ht: impact of script and document.write

danc: drag and drop and relationship to bibtex, vcard

am: commented about how they talk about datatypes - using prose
instead of BNF

lmm: conformance requirements which are not testable

ht: my related point is that there is a notion in the HTML spec is
that document conformance and UA conformance are decoupled
... not sure that this is achieved
... and whether the goal is a good one

<noahm> What I've recorded is: "The spec seems to decouple "user
agent conformance" and "document conformance". Stipulate that's a
good goal. There's a question of whether the spec. actually achieves
this. Was it a good goal in the first place?"

lmm: outline section has no exhibited behaviour in other parts of
the spec.

jar: OWL spec. has this issue too

ht: XML schema too
... W3C-wide issue about references to other specifications, also
exhibited in HTML
... don't follow guidelines suggested by Sperberg-McQueen
... MUST support at least version X, MAY support version Y, for
example

<DanC_lap> (the References section of the HTML 5 spec is fairly new;
I took a look at it, and I think it does a reasonable job on the
versioned specs issue)

nm: difference between "you've got a buggy processor" and "you've
got a processor that supports a version we haven't seen"

lmm: seems to be some assumption that a WG will remain active for
the indefinite future to update the specification as refs change,
for example

ht: have we decided about use of the term URL?
... and the 'ping' attribute?

<DanC_lap> hmm... no Zakim... how about RRSAgent? nope... jkemp,
note w3.org hasn't logged the proceedings so far

lmm: the "willful violations" sections - charset override in
particular

<Zakim> DanC_lap, you wanted to add registries to the list: rel
values in whatwg wiki, Public Suffix List from Mozilla

ht: was assigned a section about scripting
... execution model is opaque to me - can we discuss?

lmm: several examples in mind - the general issue is about
applicability of the Web
... public Web vs. private Web (intranets et al) vs. use of Web
components for things "other than the Web"

<DanC_lap> (yeah... this "only the public web matters" position
seems iffy to me. I tried to blog about it, but the comments suggest
the point didn't get across well.)

lmm: public Web split between "crawlable" vs. that which requires
authentication
... applicability of <canvas> in environments such as email

jar: javascript URI scheme is in the spec. but not registered

nm: is your issue only about registration?

jar: if done, it should be done properly

<noahm> My initial list of issues was sent to the TAG here:
[16]http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html

[16] http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html

<timbl> paving cowpaths Having spent quite some time in a country
where the roads are in fact paved cowpaths, ... I know how twisted a
road you can end up with :)
...[17]http://www.theotherpages.org/poems/chester1.html#2

[17] http://www.theotherpages.org/poems/chester1.html#2

nm: link rel issue: spec calls for processing to continue in a case
that they say is "not allowed"

<DanC_lap> (I thought we dispatched with this one ("rel attribute
must... if rel is absent..."). editor ack'd as bug and fixed it.)

ht: this says that the "document is not conforming", but tells the
UA what to do in that situation

nm: document.write cannot be used with XML serialization
... I have an XML DB to manage my HTML, and can serialize as XML,
but also want to use document.write

lmm: execution toolchain - content not written only by people
writing HTML (tools are often XML-based)
... and use-cases that led XHTML WG to do modularization
... being able to subset the specification was a requirement

nm: content sniffing?

ht: IETF has taken this on

lmm: would still like to talk about this in relation to the use of
MIME types
... register a MIME type to allow sender to tell recipient what
sender means
... and... division of responsibility between W3C, IETF and also WGs
in W3C
... Origin header, content type sniffing, URI schemes are examples

nm: would like to mention issue of inconsistent (in)formality of
parts of the spec. - borderline editorial

am: some of these things are bugs, others are "meta" issues on the
whole spec.

nm: anything can be reported individually to the WG

lmm: which of these issues are we willing to commit to as a group?

nm: I feel obligation to discuss things we think are important

<noahm> Larry has expressed the concern that the HTML draft is, in
some cases, intentionally provocative, e.g. the statement that "A
DOCTYPE is a mostly useless, but required, header." There is a
perception that this is disruptive.

<noahm> [18]http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt

[18] http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt

<noahm> [19]http://www.w3.org/2001/tag/2009/09/htmlissues.pdf

[19] http://www.w3.org/2001/tag/2009/09/htmlissues.pdf

nm: identify 5 things from the above list to discuss first
... everyone gets 10 votes, can assign multiple votes to one issue,
don't have to use all votes

<DanC_lap> hmm... 4+5 cluster, 7, 11, 15+20 cluster, 25. 26, 28

<DanC_lap> hmm... 4+5 cluster, 7, 11, 15+20 cluster, 25. 26, 28, 31

<timbl> Tim: 5: 4; 7:3; 11:2; 12:1

<masinter> 1,1,3,6,10,13,19,25,28,31

<jar> jar: 1,3,4,7,10,13,27,28,30

(group voting on issues as listed in
[20]http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt)

[20] http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt)

<DanC_lap> 3 on 15 (+20), 2 on 25, 2 on 26, 28, 31 (revision after
realizing there's more than one choice per issue)

4,7,15,16,20,25,26,28

issues 7,13,15 get the most votes

references to versioned specifications (HTML 5 review topic #15)

dc: when you link to a versioned spec. you are delegating authority
to some other spec.
... link to a static spec. it's like loading a library

ht: there is a difference between "you must use the latest" and "you
must use some version either this dated one, or later"

dc: 2 instances in HTML - allowed rel values specified to be in
WHATWG wiki
... second is mozilla decided to create a public suffix list (.com,
.co.uk etc.)

tbl: if you're looking for the legal owner of the URI go to this
list

<masinter> [21]http://dev.w3.org/html5/spec/Overview.html has
reference [PSL]

[21] http://dev.w3.org/html5/spec/Overview.html

tbl: so that delegation of authority is clear

<masinter> search for "Public Suffix List"

<masinter> 2.4.9 Reversed DNS identifiers : #

<masinter> Check that the end of the resulting string matches a
suffix in the Public Suffix List, and that there is at least one
domain label before the matching substring. If it does not, or if
there is not, then the string is not valid; abort these steps. [PSL]

tbl: below that, delegation is not open

dc: browser can then tell you "who owns the page"
... I think this shows up in the origin work
... feedback from IETF was "don't do that"

<masinter> "6.4.1 Relaxing the same-origin restriction"

lmm: (inserting into IRC some refs to "informal registries")
... spec. incorporates by value in some places - eg. vcard - one
kind of versioning
... also applies to HTML use of URIs
... then, the case of a normative ref to another specification

<ht>
[22]http://www.whatwg.org/specs/web-apps/current-work/#references

[22] http://www.whatwg.org/specs/web-apps/current-work/#references

ht: worth nothing that when we reviewed the spec, there was no
references section

<DanC_lap> (interesting... the public suffix list seems to be used
in the reverse domain label stuff in the microdata stuff)

<DanC_lap> (and only there. never mind what I said about origin and
javascript security boundaries.)

ht: refs are, for example, undated

<masinter> danc: that's only in one version

ht: URIs are undated, but reference itself has a date
... what happens when newer versions come out?

nm: so you're saying that the ref is dated, however the URI links to
the "latest" version?

ht: yes

<jar> the hyperlinks (not visible in printed version) are
non-normative, I hope?

<DanC_lap> recent discussion suggests printed versions are not
considered usable by implementors; so in effect, the links _are_
normative; i.e. they impact interoperability. (see msg from maciej.)

<DanC_lap> (darn; can't confirm from archives re printed versions)

nm: what do I need to do to see if my user-agent is conformant or
not?
... in cases like this, where references are unclear, that
conformance is also unclear
... comment might be that this is ambiguous and should be clarified

<jar> in the [XMLBASE] case the printed text says one thing, while
the URI says something else

<Zakim> noahm, you wanted to talk about clarity of spec language and
conformance

<ht> Here's my recommended text: Extensible Markup Language (XML)
1.0 (Fourth Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, and
E. Maler, Editors. World Wide Web Consortium, 10 February 1998,
revised 16 August 2006. The edition cited
([23]http://www.w3.org/TR/2006/REC-xml-20060816) was the one current
at the date of publication of this specification. The latest version
of XML 1.0 is available at [24]http://www.w3.org/TR/xml/.
Implementations may follow the edition cited an

[23] http://www.w3.org/TR/2006/REC-xml-20060816)
[24] http://www.w3.org/TR/xml/.

am: reiterates Larry's point about copying text from another spec.
(ie. vCard) and that this copy came from some dated version
... should not copy text, but reference

lmm: if underlying assumption is that WG stays active, then such
things don't necessarily matter

nm: but vague references are a problem separate from that
... for any given version of HTML can you answer the question "what
is conformant"?

lmm: answer is you read the latest HTML5 spec. and take the latest
version of every ref'd spec.

ht: (points to his prose above)

<ht> d/or any later edition(s); it is implementation-defined which
editions are supported by an implementation.

<masinter> [25]http://krijnhoetmer.nl/irc-logs/whatwg/20090920#l-219

[25] http://krijnhoetmer.nl/irc-logs/whatwg/20090920#l-219

ht: this guideline refers to W3C policy of versions vs. editions
... W3C has a strict guideline on "what is an edition"
... changes between editions are unlikely to invalidate their use

<Zakim> ht, you wanted to mention edition vs. version

<DanC_lap> ("W3C has a very strict definition of edition" yeah...
well... sorta... except we change it sometimes. :-/)

ht: more you understand about what revisions are possible, easier it
is to write things such as the above
... have to take account of the authors/documents you are referring
to
... in order to do this

jar: these specs. have contractual nature, and if you can't describe
the contract, there can be problems
... and at least you need clarity
... and decide is this what W3C should do?

<Zakim> jar, you wanted to mention w3c's brand as a standardization
org, e.g. to us govt

<Zakim> masinter, you wanted to ask Noah to say what he thinks is
ambiguous

lmm: if you presume WG continues beyond life of individual spec. and
that you'll update the spec. quickly

LM: There's a belief, I think, that efforts to guess in advance the
kind of changes that will later be needed have not done well.
Therefore, not worth the time.

lmm: trying to allow for distributed extensibility and clear
references is not worth the time
... because we have failed in the past
... architectural separation between implementation guide describing
current behaviour vs. long-term specs. that can be referenced
... would be a good place to start

ht: envisaging role of HTML WG being constant maintenance of
compatibility between browser implementations is a valuable vision
for the future
... and have a longer cycle for the HTML language

nm: 1 thing HTML WG does is to maintain the language - references
from that to external specifications should be made clearly, without
needing to revise the spec.
... as a second activity, recognize the documentation of
implementation interop as being important

lmm: WHATWG started as "how to build applications using Web
technologies"
... my definition of a platform is a set of interfaces
... WHATWG platform has a set of interfaces including JS, HTML etc.
... HTML5 combines the def 'n of the HTML language with the def'n of
the DOM API, Origin interface et al
... because the original goal was to define a platform, not one
interface

ht: should give some thought as to why this might not be seen as an
issue

<ht> What I said in response to TBL was I would recommend we request
that the HTML WG consider the matter of dated/updating references,
suggest that they follow MSM guidelines for W3C Specs, and consider
"or successors" for IETF refs, on a case-by-case basis

nm: having an always-on WG prevents a problem where you have a ref'd
successor spec. which is no longer compatible

lmm: separate the spec. into two parts - one of which is intended to
be stable, and which has stable refs
... and a second part with makes normative ref to the stable specs.

<Zakim> jkemp, you wanted to ask would it be appropriate to i) ask
that WG follows W3C practice on refs to W3 specs and ii) ask a
question to WG about the clarity of their references,

JK: As Tim suggested, why can't we go to HTML WG and say "here is
the W3C policy for referencing W3C specs", and if there's an IETF
policy for RFCs, etc.

DC: But there is no W3C policy, there's suggestions from Henry and
Michael Sperberg-McQueen

JK: Well then follow that.
... Beyond that specific advice, we can make suggestions about
general approaches.

<ht> The larger issue is about implementation coherence vs. language
specification and the impact on that division of the 'always on'
idea

tbl: challenge the always-on WG - when the spec. goes out it has to
say more than "this is the list of systems you must support"

<ht> We should be trying to understand what the best steady-state
will look like

scribe missed Tim's point

lmm: challenges johnk's point about giving the WG specific guidance
on writing references
... and whether that would be useful given the always-on assumption

nm: we either have to tell the HTML WG something compelling or say
something compelling to the wider community

ht: what do we envisage as a viable stead-state situation?
... right now we're in anomalous situation, but once we're caught
up, what should the steady state look like?
... along the lines of "we've got this story about implementations
work, and when they want to change that, because it works so well,
they'll come to us, and all the impls will change"
... so because we have this ongoing process, spec. changes are easy

tbl: but that doesn't work if you don't signal the kind of changes
that are likely
... implementations already rolled out /won't/ change

<jar> wondering what the purpose of specs, or this spec in
particular is. the fact (phenomenon) of a spec is to give a name
(e.g. HTML5) to a big pile of words. what consequences does this
have... uses of the spec (in pieces of writings) are various

nm: variety of refs here, please clarify - eg. difference between
dated ref and undated URI

<DanC_lap> (I'm listening for a particularly harmful incidence of
this "unclear references" issue. Haven't heard one yet.)

nm: be clear what your policy on references is - to ensure that
majority of readers come to same conclusion
... TAG believes there is value in signaling to community what kinds
of extensibility are possible
... as Tim said, people structure implementations along the axes of
extensibility
... please look for those - is it your intention to support properly
new versions of unicode, new image types etc. (these are just
examples)

lmm: how we define what Web technology is, is an architectural issue
for the Web
... and we should work out this framework

ht: consensus about references seems clear
... but the larger issue is something unclear, and I largely agree
with Larry that we should continue to work on that issue

danc: don't agree with the narrow (references) issue

ht: XML reference not clear

danc: relationship to XML is noted elsewhere in the spec.

(paragraph 2.2.1 XML)

nm: note danc's objection to the specific references issue

ACTION ht to draft text on writing references

<trackbot> Created ACTION-303 - Draft text on writing references [on
Henry S. Thompson - due 2009-09-30].

ACTION masinter to draft summary of the larger issue

<trackbot> Created ACTION-304 - Draft summary of the larger issue
[on Larry Masinter - due 2009-09-30].

break...

Architecture of Web Applications

<noahm> scribe: Larry Masinter

<noahm> scribenick: masinter

nm: have not committed to form of work in this area: finding, new
volume, or what

<noahm> Jonathan's revised version:
[26]http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921

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

note Jonathan not back from break

nm: suggest review against previous outline since structure seems
significantly different

jk: what is the relationship of these to AWWW? Is this a new volume?

am: might not be new volume, might be addition

nm: we tell a story in AWWW about what it means for a URI to connect
to a resource, Raman's document tells another story about what Ajax
applications do. I would like to link these stories.
... Jonathan's outline looks like a computer science slicing of the
story and issues.

ht: the original list was disorganized, we asked JAR to organize it,
he did, are you saying you don't like his organization?

nm: JAR's outline... I don't see much about URIs, resources, etc.

jk: having looked at Device APIs and .... I think there is some
linking or connection that isn't evident

tbl: Historically TAG made a mistake of trying to describe web
services as part of web architecture, but it was different, they're
different patterns
... basically though they're not the same architecture

tbl, jk: we're documenting something that's completely different

nm: the use case i have in mind... (showing google maps, zooming
around): what's going on with URIs? URI i typed in was
maps.google.com; when I click on it, the client-side application
will pop up a URI which I can copy, and then put into another
browser, and get another document which is the map for the point i
clicked on in the first map
... this is an interesting story, all of the URIs are served by
Google

tbl: when we did the original AWWW it was very spotty, we focused on
places where people didn't understand. Are there areas here where
people don't get it?

nm: most places where people get confused in web applications are
things like things that Raman wrote about
... discussion about permalink meme ...

am: if I clicked ..??... and did ?? would I get the same URI?

tbl, nm: generally, if I do the same thing, I get the same URL

tbl: ... something about interoperability of google maps & yahoo
maps ...

nm: a lot of people ask me about designing Ajax apps, and when I
tell them that, they go "Really?"

ht: in practice, this is closer to Raman's stuff
... you're saying that in practice that's the same, in principle
...it could have been done server-side...

jk: two interesting things: the server is delegating to the client
the authority to mint URIs that means something. There is a resource
authority at Google. Resource authorities author the space of URIs

am: when we start talking about devices, we'll also talk about URIs
for device state

nm: (highlights JAR document "Application State" first two bollets
on "What is state? Where is the state?"

ht: whether google maps is stateless: you can't tell from the
outside

nm: if I mail you a URI, you'll get the same document. If there were
cookies you'd get "session 12? What's that?"

tbl: it's a browser problem you can't put the permalink URI into the
address bar
... it's a trust issue, the browser should be able to make permalink

ht: it should always be the case that the address bar tells you what
you're looking at

jk: in many cases you can't bookmark things, and user's expect it

tbl: there's a lot of functionality that (appears to) hangs off the
address bar (dragging the icon, copying into email)

nm: going back and forward (demo of google maps) using the browser
back button, the URI doesn't change but the view changes. This is a
strange bit of business compared to what we wrote on AWWW
... pushback on the idea that these are separate story. These look
like documents, they should be relevant to AWWW, not be a separate
story.

am: add stuff to AWWW, not write a separate volume

nm: we're not much further than we were in june, i'm disappointed,
where does TAG want to go

tbl: I think pushing on HTML5 is higher priority than this

nm: HTML5 might not take up the whole focus
... discussion of scheduling ...
... discussion of Raman's position ....

ht: rather than optimizing the table of contents (disagreement that
what's people are doing) -- we got one more level of detail out of
Jonathan

lm: i suggest as a concrete action that we review and accept this
outline as our framework for AWWW volume 2, we accept the action of
updating AWWW volume 1 which can make reference to volume 2, and we
push the scheduling of this work to really fire up later

jk: want to see what the group wants to do on webapis
... discussion of scheduling future discussion on this topic ...
... I've written a document which explores the examples in 'old
school' API vs. new WebAPI....
... my document may bear on web architecture, jonathan's outline

nm: propose wrapping this up for now

lm: let JAR go over his outline when he gets back

HTML issue collection, cont

ht: XPath and XSLT changes in HTML are issues

am: yes.

document conformance vs. user agent conformance requirements (#13)

ht: There are bunch of MUSTs in the document, some of these apply to
documents and some apply to user agents. wherever there is a MUST
that applies to documents, there's a corresponding MUST that applies
to user agents as to what a user agent should do in such cases.
... is this a reasonable assumption?

tbl: specs generally specify protocols. "If you implement according
to the spec, then you get this benefit", and generally there's a
link between the implementaiton of the spec and the benefit
... most specs leave out the proof that links the "if you implement
this" to the "you get the following benefit"
... when one of the things you have to say is that this works on all
documents, and works on all extensions, you're right, you can show
that it's true that when there's a MUST in the document there should
be an equivalent MUST

ht: this is a challenging standard to hold the spec to

tbl: it's never been done before

ht: my prejudice is: gee it would be so much easier if I had spec A
and spec B, it would better. In my experience, having these
intertwined makes it much harder to review. I've worked through 3-4
examples of this.
... example binary values, x=yes or just writing x, x=no or writing
nothing ...
... the specifcations of what you can put in your documents and what
you do, it is hopelessly entangled, spread out in multiple documents

nm: it's possible it's spread out for other reasons
... what is the reason why it is spread out?

ht: there is language in chapter 2 section about binary attributes
which is actually language about agents. When you're looking at
chapter 9 about user agents is back in chapter 2 that you might
think you only needed to look at.
... one of the things i discovered is that browsers don't strip
white space from NM tokens. in SGML and XML white space is stripped
... simple example is the type attribute link
... ... oh i need one that is enumerated ...
... halign is either left, right or center. In xhtml you can write
halign="<newline>left" and that's fine
... in sgml it's fine. HTML4 spec says browsers MAY do whitespace
normalization. HTML5 says they must not.
... this is an example where the obvious error recovery is not
mandated in HTML5 because browsers don't implement this
... HTML5 recognizes attributes that have enumerated values

nm: if you take some of the cases where you're worried about the
treatment of errors, but here's what I want you to do... I want you
to establish a clearer convention, to separate out error recovery
logic
... would that help?

ht: it would be a good thing but it would make the spec longer and
more accessibility

nm: do you think it's the right direction to look at?

ht: there's a mixture already .... example where something clarified
was for user agents and not for documents
... discussion was link rel

<masinter_> "implementor advice" are things that don't belong in the
authoring spec

ht: discussion of distinction between specific "user agent" and
"html consumer", and DOM builder, and position about all HTML
interpreters should build a DOM
... i have this perl script that finds attributes in XML. HTML
position is everyone should work in terms of the DOM

nm: is it legitimate... to build a tool, where are the rules for a
strict parser

nm, jk: html5 doesn't specify which bits of the parser
implementation are necessary to build a parser that will only accept
correct documents?

scribe: henry looking for example ...

lm: gives example of error recovery for invalid URI characters
either signalling an error or generating illegal domain...

nm: when scripting is involved, the DOM isn't advisory, there has to
be a DOM
... HTML5 is fundamentally a script-enabled version of HTML, but
because of things like onload, if you're in a script enabled parser,
if you just load a document and run the script, the only normative
definition is when there is a DOM

jk: isn't this similar to XSLT or anogous wher eyou have X? and Y?

nm: I think the way to think about the HTML dom is that there is no
Z?, there is no static W?
... because you can inject script, can't have a clean model

lm: is there a place for HTML without document.write?

ht: it's not enabled in XHTML

nm: I think this comes from a misapprehension that XHTML would use
an off-the-shelf ....
... discussion of what else would have to be restricted to make a
simpler spec ...

tbl: different times when you can use document.write, and some
places where this causes different problems ...

nm: innerHTML is much less of a problem

<timbl> innerHTML()

nm: some of the approaches we're tempted to recommend for error
recovery don't work for things like document.write

(break)

reconvene

nm: is there a kernel of a TAG comment to the working group in an
area like this? What would it be?

lm: suggests having IRC chats with HTML-WG / WhatWG

ht: if we can craft an issue and have a consensus position, we send
a comment by email, and accept the result
... on the other hand, for example, the "always on" point, and how
much the structure and rhetoric of the spec depends on that, that
would be a topic for discussion
... a call, a joint session in santa clara
... IRC has the same drawbacks as a meeting

ACTION Noah to schedule time at TPAC for joint session with HTML WG

<trackbot> Created ACTION-305 - Schedule time at TPAC for joint
session with HTML WG [on Noah Mendelsohn - due 2009-09-30].

nm: what do we do about 3 on "error handling"

ht: html5 spec is clear about enumerated values. it is also clear
that there is a correspondence of properties of dom nodes, what
happens if i write input something??=banana, i can't find out what
happens
... the correspondence between document conformance and error
recovery isn't not clear
... having told that detailed story, the higher level story is ...
what about a question of the form, "please make explicit connections
between document conformance and error recovery which user agents"

nm: the form of our feedback would be that someone would draft
something?

ht: i just asked on public-html-comments, if the answer was there
was a bug

s/something??/disabled/

<ht> s/isn't not clear/isn't clear/

<ht> s/agents"/agents must carry out for non-conformant documents"/

nm: tasking to frame an issue is better

discussion of work on webapis

review of JK document

[27]http://www.w3.org/2001/tag/2009/09/apis-on-the-web.html

[27] http://www.w3.org/2001/tag/2009/09/apis-on-the-web.html

lm: i see the cases, think i understand the examples enough, what is
the differences

ht: what is window.navigator

jk: took this example out of geolocation spec

nm: the operating system decides when it has interesting information

ht: example should include numeric parameter of amount of rainfall
... discussion of example and whether there is two or one web page
...
... discussion of cars as rain guages ...

<timbl> meteo = rdf.load(NadiasMeteo); rain=meto.the(NadiasSensor,
rainfall)

ht: URIs being minted by client ... discussion of resources and URIs
in the two examples ...

<timbl> or kb.looup(NadiasSensor); rain=meto.the(NadiasSensor,
rainfall)

nm: how am I going to implement this?
... if you're using web infrastructure use the terminology of web
... geolocation draft ... does the TAG want to make a recommendation
about that draft on the use of URIs for this?

ht: Why does it make sense to think that any device that have state
that is useful for web applications should give IP addresses to
them?

lm: could we suggest that, in the design pattern where client sends
request to server, gets back content which interacts with local
state, uses that state to customize information, and then presents
information to the user based on state, that the information used
(or the state used) should be serializable?
... trying to get back to the permalink idea
... or that google maps & yahoo maps might interoperate?
... trying to see if there's a distinction between "geographic
location" and accelerometer

<jkemp> [28]http://phonegap.pbworks.com/JavaScript-API shows an
accelerometer JS API, for example

[28] http://phonegap.pbworks.com/JavaScript-API

nm: maybe standardizing way temperature is embedded in a URI or
query string ... seems funny
... does this need to be standardized?
... discouraged metadata in URIs? Lattitude & Logitude

am: what about this case?

nm: what resolution? What privacy and security issues?

<timbl> [29]http://www.w3.org/2009/09/Nadia/meteo#sensor

[29] http://www.w3.org/2009/09/Nadia/meteo#sensor

lm: question about extensibility of GeoLocation to civic location

nm: this is following to the letter the guidelines for javascript
APIs

lm: where are the guidelines for writing extensible API
specifications?
... discussion of whether TAG should give guidelines ....

<jkemp>
[30]http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.htm
l

[30]
http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html

nm: what are our priorities? suggestion was made that it was new.
not like device stuff is first example? Should the tag be looking at
or saying interesting things about this?

am: what would we update in the architecture?

<jkemp> * Scripted APIs, as currently specified are possibly not
self-describing (and one might not be able to "follow one's nose" to
access data exposed in this way)

<jkemp> * There is no HTTP-like "uniform interface" yet described
for scripted APIs

<jkemp> * The impact of state on the presence and usage of an API
(for example, how DOM events can affect the results of an API call).

<jkemp> * URIs to resources exposed via scripted APIs (especially in
the case that a URI does not exist for such a resource)

jk: these came from meeting w/Ashok

[31]http://lists.w3.org/Archives/Public/public-geolocation/2009Jul/0
020.html

[31]
http://lists.w3.org/Archives/Public/public-geolocation/2009Jul/0020.html

privacy & security in APIs?

scribe: discussion of geopriv, policy languages, etc...
... whether services that suck your conact list...

am: who is going to enforce this?

dc: if they share the info and get caught they would be busted

am: whoever has access is somehow identified

lm: belief is that it is one bit "public or not"

jk: EU laws, indicate the user agreed to some action
... discussion of 'evil' bit ...
... we tried to use P3P, didn't gain any adoption or consensus

tbl: are they all armchair programmers?

jk: design patterns for extensibility good tag topic, not restricted
to APIs ..
... there are some minor issues here, then there are some other
issues that have broader context....
... other issues that are broader

nm: two statements: (1) there are a bunch of people doing APIs in
javascript, mostly don't need the tag's help
... (2) the tag is here to areas where things are not coming out as
well as it should, and if the TAG gets involved
... I don't hear people popping up and saying "that's not an API"

jk: many people are proposing a way of doing versioning

nm: there are many people who are doing it already

tbl: versioning is icing on the cake, the main problem is that there
is no modules
... if you're using google maps and yahoo maps the two aren't
compatible

dc: panel discussion, as it was breaking up.... can we have the same
thing for loading modules?

nm: if we made a blog posting, that this remains a problem, this
really is troubling?

lm: ECMA & W3C at TPAC question?

is there a meeting planned?

sorry, TC39 and HTML

if we're discussing modularity and APIs

ht: this is one of the 5 unknown problems in Computer Science

tbl: various pieces of software have to do the loading

danc: who makes up package names? debian developer community is
'always on'

jar: replacing short names with URIs

ht: , app.get(banana) changes from week to week

dc: debian community is mutually trusting

tbl: they should be using URIs, for distributed extensibility

jar: necessary level of indirection because of the architecture

tbl: search path, can search things in sequence

<ht> s/Computer Science/practical Computer Science/

<ht> s/unknown/unsolved/

lm: concern about apis using enumerations and characterizing which
apis are supported by which category the device or service is vs.
characteristics or features...

tbl: what about a thing which is a 'calendar' but there are 17
calendars and choose between whether it's a calendar and or a phone

nm: mixins

jar: we have a language for describing things, it's OWL
... this technology covers a large space of the problem

dc: compare this to the user agent header

lm: User Agent is an example of where the web community didn't get
it right

dc: user agent field allows you to know about 'bugs'

nm: gets device characterization

dc: what gets widely deployed are databases that match user agent
fields to database

nm: please give me a short thing

dc: user agent field for iPhone is long

<noahm> Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en)
AppleWebKit/420+ (KHTML, like Gecko)

<noahm> Version/3.0 Mobile/1A543a Safari/419.3

dc: lists all the features because user agent

jar: is this part of a sql query?

action larry to work with JK and AM to update Web APplication
architecture outline based on discussions at TAG meetings

<trackbot> Created ACTION-306 - Work with JK and AM to update Web
APplication architecture outline based on discussions at TAG
meetings [on Larry Masinter - due 2009-09-30].

<noahm> CLOSE ACTION-300

<trackbot> ACTION-300 Prepare draft on device APIs closed

wrap up for the day (agenda review)

action danc to raise issue of work items moving between W3C working
groups and also with IETF

<trackbot> Created ACTION-307 - Raise issue of work items moving
between W3C working groups and also with IETF [on Dan Connolly - due
2009-09-30].

<noahm> Closing action 273

<noahm> ACTION-295 Due 25 Sep

<trackbot> ACTION-295 Monitor geolocation response to IETF GEOPRIV
comments on last call and report to the TAG due date now 25 Sep

<noahm> ACTION-301 Due 24 sep

<trackbot> ACTION-301 Review websocket protocol/api motivation and
brief TAG at Sep ftf due date now 24 sep

Summary of Action Items

[End of minutes]
_________________________________________________________

Minutes formatted by David Booth's [32]scribe.perl version 1.134
([33]CVS log)
$Date: 2009/10/12 17:21:32 $

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

[1]W3C

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

- DRAFT -

TAG f2f, day 2

24 Sep 2009

[2]Agenda

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

See also: [3]IRC log

[3] http://www.w3.org/2009/09/24-tagmem-irc

Attendees

Present
Tim Berners-Lee, Dan Connolly, John Kemp, (in part), Ashok
Malhotra, Larry Masinter, Noah Mendelsohn, Jonathan Rees,
Henry S. Thompson, ( Lisa Dusseault and Mark Nottingham by
invitation, in part, by telephone)

Regrets
T. V. Raman

Chair
Noah Mendelsohn

Scribe
Henry S. Thompson (morning), Dan Connolly (afternoon)

Contents

* [4]Topics
1. [5]Metadata
2. [6]Content-type sniffing
3. [7]Web Application Architecture
4. [8]Naming Schemes
* [9]Summary of Action Items
_________________________________________________________

Metadata:
[10]http://www.w3.org/2001/tag/2009/09/23-agenda.html#metadata

[10] http://www.w3.org/2001/tag/2009/09/23-agenda.html#metadata

[Two updates for agenda: sessions likely on Javascript security and
Distributed extensibility]

AM: Hoping for drafts from Mark N. and Eren to start from. New draft
has arrived from Mark N., "?? well-known URIs" [ref?]. Apparently a
replacement for the site-meta draft, quite short. JAR likes LM's
suggestion that we work on a whitepaper surveying the state of play
wrt metadata

<DanC_lap> (I didn't get the impression that the well-known URIs
draft was a replacement for site-meta)

<noahm> Well, Dan, the title certainly makes it sound different. I
haven't read it yet. Do we have a link?

JAR: I took an action [ACTION-282] to draft a document in this area,
which got closed for lack of action but I'm willing to resurrect
this because I expect to have some time available not just formats
and transport, but also life-cycle

<DanC_lap> action-281?

<trackbot> ACTION-281 -- Ashok Malhotra to keep an eye on progress
of link header draft, report to TAG, warn us of problems (ISSUE-62)
-- due 2009-08-01 -- OPEN

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

[11] http://www.w3.org/2001/tag/group/track/actions/281

<noahm> ACTION-281 Due 30 Oct

<trackbot> ACTION-281 Keep an eye on progress of link header draft,
report to TAG, warn us of problems (ISSUE-62) due date now 30 Oct

<noahm> action-282?

<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
metadata architecture. -- due 2009-08-31 -- CLOSED

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

[12] http://www.w3.org/2001/tag/group/track/actions/282

<noahm> Action 282 was reopened by editing the record, now has note
stating: Reopened at Sept 2009 F2F because Jonathan says he is doing
a draft after all. Expected to cover both access and formats (and
maybe more).

<noahm> The action numbered 282 is now due Oct 13

JR: Next step will be a draft

LM: I'll be happy to contribute effort

<DanC_lap> action-282?

<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
metadata architecture. -- due 2009-10-13 -- OPEN

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

[13] http://www.w3.org/2001/tag/group/track/actions/282

Content-type sniffing:
[14]http://www.w3.org/2001/tag/2009/09/23-agenda.html#sniffing

[14] http://www.w3.org/2001/tag/2009/09/23-agenda.html#sniffing

<noahm> Preparing for call with Mark Nottingham and Lisa Dusseault,
which will be in about 30 mins

DC: My starting point is the example of serving XML as text/plain,
because you want to show the angle brackets but if you have various
magic strings near the beginning, browsers will treat it as HTML
anyway. Ian Hickson fought this for 10 years, then gave up and wrote
a description of it (sniffing) into the HTML 5 spec. This was
queried as it wasn't HTML, but rather HTTP. So Adam Barth took the
relevant bit out and wrote it up as an Internet Draft. Not clear
where this draft is heading. Both groups (HTML WG and HTTP bis WG)
have closed their issues on this

NM: What are Lisa and Mark's roles?

DC: Mark is chair of HTTP bis WG, Lisa is relevant IETF Area
Director. Should we leave the unsatisfactory status quo in place, or
try to expose the unsatisfactory nature of the resolution?

LM: This is a kind of error-recovery issue. Browsers are trying to
accommodate users who have tried to publish HTML, but are getting it
served as text/plain, or who are publishing images with the wrong
mime type, typically through no fault of their own

JR: But it's an odd kind of error -- it's undetectable. I've been
burned by precisely DC's example

NM: Example here:
[15]http://www.hoahdemo.com/rte/Metadata/broken_text.xml

[15] http://www.hoahdemo.com/rte/Metadata/broken_text.xml

<noahm> (I may or may not leave that content up there for the long
term...it's a page I put together mostly for my own use, but it's
fine for everyone to try it.)

LM: Hixie is just documenting a compromise position wrt what the
browsers are doing already

<DanC_lap> (Fielding gives a colorful history of the sniffing issue.
I wonder whether to bring it up orally.
[16]http://lists.w3.org/Archives/Public/public-html/2008Jul/0038.htm
l )

[16]
http://lists.w3.org/Archives/Public/public-html/2008Jul/0038.html

HT: My understanding is a bit different from what Dan said. I
started out believing we had a problem. I said in my notes
"shouldn't the fact that Adam Barth's draft is incompatible with RFC
2616" at least be acknowledged in the HTML spec. But, if I "follow
my nose" from HTML issue 5 I get to this message

<ht>
[17]http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0473
.html

[17]
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0473.html

<DanC_lap> (I don't think 5 is the right number)

<DanC_lap> relevant HTML WG issue is
[18]http://www.w3.org/html/wg/tracker/issues/28

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

HT: In that, Mark Nottingham says that sniffing does not conflict
with RFC 2616. That issue is closed, but it's not quite clear from
Tracker what logic was used to close it.

DC: We discussed this before, and you agreed.

<ht> [19]http://trac.tools.ietf.org/wg/httpbis/trac/ticket/155

[19] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/155

HT: For HTTPBis, it's issue 155, which appears to say that "provided
user controls are in place, sniffing will be allowed."

<DanC_lap> "HST: OK, thanks for clarifying, I understand better now"
-- [20]http://www.w3.org/2001/tag/2009/09/10-tagmem-minutes.html

[20] http://www.w3.org/2001/tag/2009/09/10-tagmem-minutes.html

HT: Seems to contradict Dan's saying that a user surveying pertinent
specs won't discover the problem. I think if HTTPbis goes this way,
we'll have to revisit the authoritative metadata finding.

DC: Would like to see what Henry is referring to.

HT: From HTTP bis issue 155:

HT: The language should be updated to reflect this reality,
without unduly encouraging the use of sniffing except where
necessary. Ideally, it will be done in such a way that:

* Does not require sniffing for all uses of HTTP (i.e., a
particular implementation and/or user can "opt in" to the use of a
sniffing algorithm), since this is most commonly a problem for the
browser case, and

* Specifically allows a user and/or content provider to opt out of
the use of sniffing in a particular interaction, and

* Promotes interoperability (i.e., if two implementations sniff,
they will do so in the same way).

DC: But they didn't do that.

DC: Looking at ticket 155. . .

<noahm> Note proposal 8 weeks ago:

<noahm> Proposal from HTTP WG meeting: remove the sentence:

<noahm> "Note that neither the interpretation of the data type of a
message nor the behaviors caused by it are defined by HTTP; this
potentially includes examination of the content to override any
indicated type ("sniffing")."

NM: It appear that the HTTP bis WG has in fact done that deletion

<masinter>
[21]http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-07

[21] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-07

NM: looking at section 3.2.1 in current draft having difficulties

<DanC_lap>
[22]http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-07#sect
ion-3.2.1 perhaps?

[22]
http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-07#section-3.2.1

<DanC_lap> "Note that neither the interpretation of the data type of
a message nor the behaviors caused by it are defined by HTTP; this
potentially includes examination of the content to override any
indicated type ("sniffing")."

DC: Not clear if this has been removed

<Zakim> noahm, you wanted to ask about functions vs. specs

NM: Two issues for the TAG:
... 1) How strong do we feel about this?
... 2) What does and should the specs say?

<DanC_lap> (so indeed, it'll be handy to have Mark help us navigate
their issues list and tell us what the status of this issue is.)

NM: We all agree that in the real world this shouldn't be necessary.
But how can the TAG be helpful given the exigencies of the real
world where it is?

DC: I think the Authoritative Metadata should be revised. RF said
"over my dead body" wrt that proposal some years ago

<noahm> [23]http://www.w3.org/2001/tag/doc/mime-respect

[23] http://www.w3.org/2001/tag/doc/mime-respect

HT: No, I remember the exchange: the TAG's position is (was) don't
do that. period.

TBL: The architectural rule is "don't do it"

TBL: That's still the right architectural decision, and when it's
not observed there's damage

<Zakim> timbl, you wanted to wonder about a practical solution being
to involve the user and keep a per-site kludge list like for "bad"
certificates.

TBL: You could address this by browsers have a way to record user
preference to see some 'text/plain' as appl/xml then you could
generalise to "should I always treat text/plain from [this site] as
appl/xml?"

LM: But there's no point in writing a spec. if browser makers won't
attend -- true or false?. I haven't been able to rebut this

TBL: For example, wrt certificates, we argued for years to improve
things, and they finally moved. We could find out what the facts
are, and if we made a proposal which helped the browsers, they might
find it helpful

LM: So, we could say we don't want W3C to publish a spec. which
encourages sniffing

DC: Not without showing a way out of the current local minimum.
Could we build an extension which illustrated TBL's suggestion?

HST: Depends on whether there's a hook in Mozilla for this case?

DC: Or we could ask for a hook -- that's easier than asking for a
change in the UI

[Lisa Dusseault and Mark Nottingham join the meeting via the 'phone]

NM: Thanks for joining us to discuss sniffing. Our starting point is
that architecturally sniffing is bad, but maybe there's a case for
at least documenting the workarounds for the practical difficulties
caused by misleading media types

MN: Our issue 155 is about sniffing

MN: we came to consensus that HTTP should get out of the business of
ruling out sniffing and just say that Content-type: is for users to
indicate what they think, but not say "don't sniff". So don't
encourage it, and certainly not require it, but stop making it
non-conformant to do it. Then there can be a draft such as Adam
Barth's. There was discussion about including something in the HTTP
bis draft itself on how to sniff, but we didn't go there

NM: Stable now? Anyone pushing back?

HT: The last decision we see recorded on your issue 155 seemed to be
to remove the text.

MN: I believe it's stable

HST: But you appear to have removed the spec. which allows it

<DanC_lap> "nothing in the HTTP spec that says you can't". so the
spec is silent on it.

MN: But there's nothing which rules it out -- we pulled that text
because some people thought it went too far towards encouraging
sniffing

LD: We've told Adam Barth that to take his work forward, he would
need to either: 1) Form a WG around this topic to take it forward;
2) Get it encorporated in the HTTP bis draft (although MN has
declined to do this for the time being); 3) Get an Area Director to
sponsor its publication as an Informational [RFC]

NM: Could HTML 5 reference an Informational normatively?

LD: That's a complex question of how W3C and IETF processes
interact. . .

LM: We're still dancing around the question of what the right
behaviour is wrt the fact that deployed software does error recovery
which is heading for being embedded in standards. I'd like to avoid
having this stuff ping-pong between W3C and IETF

TBL: I put myself on the queue to say I would like a name for a
clean HTTP. If there's sniffing in it, call it something other than
HTTP -- HTTP_unclean. We should continue to promote the clean
version

NM: Do you want the difference in-band in the requests?

TBL: No

DC: Wrt ping-pong, when one org's group starts overlapping with the
other's, there has to be interaction at least we got the overlap
area broken out into its own draft but the HTTP bis WG has decided
to be silent about this. So the question has become whether to
reabsorb the AB draft, or sight it as Informational

LD: I don't know about your process, but we have an explicit
mechanism in our process for referencing an Informational

DC: You can do it unless someone complains

LM: It's like referencing a Note -- can you do that normatively?

HST: Yes

DC: Unless someone complains and it's upheld

<noahm> [John Kemp arrives]

MN: We were asked to confirm that HTTP bis doesn't conflict with
sniffing, and we decided to accept that. At the moment we're waiting
to see where AB's draft goes. It's not strictly speaking in our
charter to incorporate it. But we could revisit that if we needed to
-- might require agreement from Lisa. Wrt HTTP_Unclean, we should
come up with a browser profile for HTTP usage, which said "use [this
URI cleanup] and [this sniffing] specs in this way". So it would be
a separate profile, rather than forking the HTTP spec itself

TBL: So documenting a set of willful violations would be a good
thing?

MN: We're coming to the conclusion that it's not a violation

<Zakim> masinter, you wanted to ask whether there have been other
cases where stuff has bounced over the boundary between application
semantics and protocol semantics

MN: Remember WSI -- they built profiles by combining other specs --
HTML 5 should be a spec. for a language, and a story about browser
behaviour should be told elsewhere, in a similar way to the WSI
stuff

LM: HTTP defines the protocol and what it means, and the browser
spec. specifies how it uses the protocol, with some wrapping/post-
and pre- processing. E.g. "HTTP says this is 'text/plain', but in
such-and-such a case, you should ignore that and use ... instead" is
there another example of this?

MN: Content-type and Content-encoding

LM: That's for browsers -- any other applications -- using SIP (?)
for instance?

MN: Not aware of any. . .

LD: There is some precedence for one IETF spec. saying "MUST" which
overrides a "MUST NOT" in another spec.

LM: What about CRLF in mime vs in HTTP -- HTTP overrode that to
match current practice

MN: Yes, header length and header wrapping minutiae -- HTTP is not a
mime protocol but its a mime-like protocol. . . .

HT: Part of the TAG history, is that when we last discussed this
issue, in the context of our "Authoritative Metdata" findin", we
decided not to change it. The finding thus continues to say that
authoritative metadata is binding. We believe that finding author
[editor?] Roy Fielding's view is that changing this would be "over
his dead body". Seems like people are feeling "worn down". I think I
know what Roy would say. But...

MN: Hard to answer

<Zakim> lisa, you wanted to try to sum up current consensus

MN: We did pull that text we talked about, because it was too
explilcit -- "not in our spec.", what they do in their own specs is
on their back

LD: We are doing more reality-based protocol design, less policing.
Maybe this means lots of health warnings. So e.g. Geopriv clients
shouldn't accept 'text/plain'....

MN: The concerns haven't been so much around purity, as around the
viability of this as a long-term solution

<timbl> Go not gently into that good night -- but fight, fight
against the dying of the light. [From Dylan Thomas Do not go gentle
into that good night]

LD: Having a real document setting out how it can be done reasonably
well changed the debate

TBL: But it's harmful, it makes things break -- we can't forget
that. If you intentionally serve some XHTML as text/plain, as an
example, it's just broken if that isn't displayed as such

<noahm> Example that breaks browsers that sniff:
[24]http://www.noahdemo.com/rte/Metadata/broken_text.xml

[24] http://www.noahdemo.com/rte/Metadata/broken_text.xml

TBL: there are also potential security holes. It makes specs more
complicated. It's important to describe the system which works as
the architecture specifies

<noahm> The example is meant to illustrate a bug reporting system,
in which the desire is to show the user buggy XML as text/plain.

TBL: and separate out the accommodations. I'd like a browser to
prompt me before using sniffing to decide how to render, so I can
decide whether I want this done for this site

NM: Positive steps?

TBL: I like the idea of a browser profile -- put all the kludges and
fixups there. But I don't want HTTP to include a sniffing section

NM: So the current HTTP spec. is OK by being silent?

TBL: I'd prefer it to point out the damage the comes from sniffing,
but also reference the AB draft

<HST:> HST thinks "Your foot, your gun, your bullet"

LD: Yes, we are trying to work that way

NM: If the TAG were to undertake to produce a finding or a REC of
the form "Here are guidelines for using internet protocols and
formats such as HTTP and media types and ... in a style which meets
the needs of the browsing community" which would either explain how
or point to e.g. AB's draft on how to do this, and point out the
pros and cons is that what you had in mind TBL, and should the TAG
do it?

<masinter> I like this: MIME types, URIs, HTTP protocol, maybe other
IETF BCPs?

TBL: I think it should happen elsewhere

NM: More to do with LD and MN?

HST: No

NM: MN and LD, anything more?

LD: Better coming from the community

NM: Thank you very much for joining us

<lisa> thanks that was useful to me too

[LD and MN leave the call]

<DanC_lap> some clues on mozilla hooks re media types:
[25]http://brh.numbera.com/blog/2009/02/24/jsonview-view-json-docume
nts-in-firefox/

[25]
http://brh.numbera.com/blog/2009/02/24/jsonview-view-json-documents-in-firefox/

[adjourned for break until 1105]

[resuming]

NM: Agenda discussion -- more on sniffing, or. . .

DC: Sniffing, maybe. How to clean up metadata:. List of legacy
sites. Treat as text/plain option (extension). Opera already has a
list of sites which it patches CSS for or some such. There is a FF
extension which allows JSON to be viewed instead of 'Save As...' so
maybe there could be a generic show as text/plain extension

NM: What about an 'i really mean it' media type header?

HST: Microsoft tried it, didn't they?

TBL: I thought that would have been fine, yes

HST: How does the user indicate to turn that on

TBL: It's turned on by default for new sites

NM: [an untarring example?]

<masinter> example was whether web hosting sites provision servers
by installing (untarring) old blog software that had bug that images
were served as text/plain

JK: Suppose the user maliciously serves javascript as text/plain,
Adam Barth says this is a security hole

DC: This hole requires sniffing for the privilege escalation to
happen

NM: But if you had a switch that said "don't do that", there's not
escalation

DC: [draws and speaks to a timeline]

HST: Does or does not AB's draft mandate leaving explicit text/plain
alone?

[WG reviews the AB draft:
[26]http://tools.ietf.org/html/draft-abarth-mime-sniff-01]

[26] http://tools.ietf.org/html/draft-abarth-mime-sniff-01

JK: OK, explicit text/plain must be left alone

DC: So that's FF behaviour, not IE

<jkemp> (section 3 of AB draft, Web Pages, step 3)

NM: What about images served as text/plain

HST: I think that's caught as binary by the algorithm

[WG goes back to the draft]

TBL: It's not the format that's safe/unsafe, it's what you do with
it. Safari is confused about this. I think this is worth saying

LM: I can see no motivation for ever sniffing postscript or pdf. I
believe that Adobe folks thought this wasn't important to sniff if
it did happen. What's the use case? Or for XML?

TBL: Because stuff is served with no Content-Type?

NM: It's plausible to me that there's PDF being served with no
Content-Type

DC: The goal is to get to the point where if you mislabel your
content you will have to fix it. The new idea is to bake the list of
sites which need to be sniffed into the browsers

LM: If for the only things mislabelled at a site wouldn't give any
clear benefit to users if they were sniffed, then they don't need to
be on the list

HST: How's it going for IE8 wrt conformance opt-out?

DC: I understand this includes a baked-in list of known-need-fixing
sites

TBL: I support this

HST: It's an important precedent for shipping strict and allowing
exceptions to be logged

<Zakim> timbl, you wanted to note that the browser can generate the
lists before it starts using it, if you allow a bit of feedback.

<masinter> i think we should push back on sniffing, that there needs
to be a clear user benefit to someone for sniffing, that it isn't
enough that there's some content that browsers currently sniff, it
actually has to be shown to be important

TBL: The list of legacy sites can grow in a distributed fashion

DC: Lots of cleverness possible here

<masinter> I don't think we should rely on the wisdom of browser
implementors to have actually done the thing that is best for their
users, some browser "error correction" behavior might have been
speculative

NM: What about the "i mean it" flag?

DC: We don't know what the facts are. . .

NM: DC, next step?

DC: Ask Microsoft to do this?. Seems to me this would work

LM: I have come to wanting to push back on the sniffing draft as
being speculative that is, codifying what browsers do, minus
escalation. A lot of these may have been speculative patchup by a
browser implementor but assuming that all of these are actually in
users' interests is dubious. Maybe they were just generalising
unnecessarily. We need to see clear user benefit before we endorse
this, line by line

HST: Isn't sniffing PDF when you have the 'unknown type' case a user
benefit?

LM: No -- I think unknown should always take you to
application/octet-stream, and users have to choose to ignore or
save. Then it's their choice to try it as PDF

NM: Maybe it would be good to find out if the current algorithm is
desirable wrt user benefit, but independently of that, documenting
what current practice is is useful

<masinter> i am opposed to mandating (rather than describing)
behavior that has no clear user advantage, especially where that
behavior is at odds with other specifications

NM: What the TAG should be doing is documenting what is or isn't
good about that, and how it's architecturally good or not

LM: I think the clear priority of the [HTML] WG is to match reality,
and that's not what users need, but what browsers do there's some
correlation, but it's not perfect the pressure to ship is sometimes
primary

<jkemp> if there is the opportunity to do something clever without
negatively impacting security, I think we should leave that
possibility open

NM: Disruption to users is presumably high on the WG's list, we have
to be careful

<masinter> i wasn't arguing this on "architectural purity" grounds,
but on "must have clear user benefit"

HST: Note that contrary to what LM implied, the AB draft goes beyond
just documenting what browsers do, by ruling out priviledge
escalation. . .

DC: LM actually acknowledged that security concerns had led to some
changes

HST: OK, sorry, missed that

TBL: There have been strong statements from the HTML WG that
browsers that don't do sniffing suffer in the marketplace maybe
everybody has converged, so there can't be any hard evidence

<Zakim> masinter, you wanted to say that NM was arguing against a
strawman

TBL: by maybe it can have gone to far

LM: I'm not saying that some sniffing doesn't have user benefit but
that not all of the draft stands up to that test. For example
sniffing postscript is pointless, given that most browsers won't do
anything with the information anyway

<DanC_lap> (timbl re "treat as text/plain", fyi, LeeF just told me
about [27]http://www.spasche.net/openinbrowser/ which seems to
support that.)

[27] http://www.spasche.net/openinbrowser/

NM: But that would compromise vendors ability to say "This version
is backwards compatible with last years", full stop. and not by
cases.

<DanC_lap> ("This extension won't be useful anymore once Bug 57342
and Bug 258012 have been implemented.")

NM: what next?

DC: 1.5 hours on Friday to write a blog post about Hixie's draft?

<noahm> close ACTION-257

<trackbot> ACTION-257 invite Mark Not or Lisa D to revisit progress
in IETF/HTML liaison on content sniffing closed

DC: What about updating authoritative metadata?

HT: Shouldn't that wait on seeing what httpBis says?

HST: I heard TBL say things which suggest we should push back on the
current state of the HTTP bis draft. Because it doesn't say "Don't
do that: sniffing breaks things"

NM: [ proposes update to Self-describing Web, because it assumes
Authoritative Metadata]

DC: +1

<DanC_lap> (what Noah is saying is what I have in mind. We don't
change the architecture, but we do FYI: widely deployed practice
diverges in the following ways...)

<noahm> Right. I would change SDW to say: the chain of
specifications holds only insofar as you act on the authoritative
metadata. That said, if sniffing goes ahead, users should be warned
that they may sometimes be shown information inferred from sniffing,
that such information is not in all cases traceable to the SDW chain
of specs, and thus is to some degree suspect.

DC: I don't think we should change the fundamental conclusion of
Auth. Metadata, but we should clarify that the world hasn't agreed
100%

<jkemp> here's a diff of the changes to HTTPbis for sniffing:
[28]http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/155
/155.2.diff

[28]
http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/155/155.2.diff

NM: I think we can be confident that some justification for browsers
continuing to sniff will be forthcoming so let's go ahead and
explore updating those two findings

<scribe> ACTION: John to propose updates to Authoritative Metadata
and Self-Describing Web to acknowledge the reality of sniffing, due
2009-10-20 [recorded in
[29]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action01]

[29] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action01

<trackbot> Created ACTION-308 - Propose updates to Authoritative
Metadata and Self-Describing Web to acknowledge the reality of
sniffing, due 2009-10-20 [on John Kemp - due 2009-10-01].

HST: Are we happy with the state of the HTTP bis draft wrt sniffing?

<DanC_lap> jkemp, are you confident that diff is after the WG
decision that mnot informed us of?

[pause to find authoritative draft of IETF bis part 3]

[30]http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-07

[30] http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-07

NM: Do we believe they are still planning further changes to the
draft at that URI, or is it likely to come out in the current form?

HT: Seems like more changes coming.

NM: OK, then I think it's premature for us to plan a response.

<ht>
[31]http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf
-httpbis/latest/p3-payload.html

[31]
http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html

<ht> That URI does identify the text after the edit we have been
discussing, to remove the final paragraph of 3.2.1

<DanC_lap> (remind me where the remaining sniffing text is? it
doesn't use the word "sniff")

JK: Another important change, is that an 'if-and-only-if' was
removed from the no-content-type case

trackbot, status?

<scribe> ACTION: Henry S. to bring back proposed TAG pushback on
sniffing and HTTP bis draft
[32]http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf
-httpbis/latest/p3-payload.html, or his recommendation that we leave
it alone [recorded in
[33]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action02]

[32]
http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html

[33] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action02

<trackbot> Created ACTION-309 - HST to bring back proposed TAG
pushback on sniffing and HTTP bis draft
[34]http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf
-httpbis/latest/p3-payload.html, or his recommendation that we leave
it alone [on Henry S. Thompson - due 2009-10-01].

[34]
http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html

[adjourned until 1345 for lunch]

[resuming]

<DanC_lap> js sec, plenary, writing session, what got booted...

<DanC_lap> again, on ECMA foo: Archived-At:
<[35]http://www.w3.org/mid/4ABB67E8.4080408@...>

[35] http://www.w3.org/mid/4ABB67E8.4080408@...%3E

<noahm> ACTION: Noah to check with Sam Ruby on ECMA/W3C activities
at TPAC [recorded in
[36]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action03]

[36] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action03

<trackbot> Created ACTION-310 - Check with Sam Ruby on ECMA/W3C
activities at TPAC [on Noah Mendelsohn - due 2009-10-01].

<jar> [37]http://www.w3.org/TR/WebIDL/

[37] http://www.w3.org/TR/WebIDL/

<DanC_lap> also note work on a WebIDL checker
[38]http://lists.w3.org/Archives/Public/spec-prod/2009JulSep/0000.ht
ml

[38]
http://lists.w3.org/Archives/Public/spec-prod/2009JulSep/0000.html

<DanC_lap> scribenick: DanC_lap

agenda order is 1, 6, 2

agenda order is 1, 3, 6, 2

Web Application Architecture

action-284?

<trackbot> ACTION-284 -- Jonathan Rees to flesh out the Web
Application ( [39]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
) outline with as many sentences as he can -- due 2009-09-15 -- OPEN

[39] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

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

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

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

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

discussion of level of interest, expertise, etc. ...

<masinter> +q to look for areas where this isn't just "good CS",
i.e., things that make this web architecture vs. architecture

discussion of parallels with work on WebArch v1

<Zakim> masinter, you wanted to look for areas where this isn't just
"good CS", i.e., things that make this web architecture vs.
architecture

JAR: I touched on that in "Goals: Network effects, overall user
experience (not just at your site), robustness, enabling automation.
You should read this document if and only if you care about these
objectives."

LMM: the 2 I can think of are: relationship beetween the
static/document web and the semantic web and the application web the
google maps URI for something was a good example. [of ...? scribe
might have missed a bit]
... 2) trust. in AWWW [webarch v1] there's discussion of authority
and ownership, which is a sort of trust model...

HST concerned he's missed some of the scribe log -- RRSAgent wasn't
watching -- we seem to drop into the middle of the web sockets topic
http://jkemp.net/tag/hybi.html -- DanC, do you have local copy?

<masinter> if I'm running web sockets and i'm talking to someone i
know is running web sockets, that's the simplest method, we'll just
talk websockets

LMM: e.g. it might be used to get stock quotes, but not by a RESTful
GET on a stock price resource.

<masinter> but if you're over port 80 and you're in a hotel and it
is noon, port 80 request might get intercepted and the hotel ask you
to log in and pay for another day's internet access

LMM: no links, bookmarks, etc. ... like web services

HT asked for a motivating example in order to get context for [which
question? scribe lost the train of thought]. We go back to slide
1... IM, multiplayer gaming... TBL suggests collaborative
spreadsheets

HT: years ago Richard Tobin and I did [42]this sort of thing in a
RESTful way... with URIs for the interesting things...

[42] http://www.hcrc.ed.ac.uk/~ht/hotknit/index.html

JK: yes, people do these things over HTTP, in a RESTful way, but
they run into issues... proxies buffer multiple events into one
response another: the 2 connection limit from RFC2616 [which LMM
points out has been relaxed in HTTPbis]...

LMM: the reasons for that 2 connection limit are historical; it's
been replaced by "do the right thing"

JK: 3) the UPGRADE header is not passed along by proxies

DC: huh? how did UPGRADE come up in a list of issues re RESTful
access?

<Zakim> DanC_lap, you wanted to ask LMM more about IETF status of
hybi wiki and to note the presentation I saw at the SFO IETF
convinced me you need 2 HTTP connections

HT: Why do Bayeux and BOSH need to use Upgrade: ?

DC: I saw a presentation on several of these. One was from Jabber
XMPP suggested best design is two connections.

NM: To avoid deadlock?

DC: Maybe, or might have been Javascript issues. Anyway, Websockets
is only one connection.. Larry, you said are we aware of hybi, and
we said yet. Then you said something about working group. Is there a
working group?

LM: There was BOF and discussion of proposed charter

DC: on hybi... when is it likely to be an IETF WG?

LMM: at the Nov IETF meeting in Hiroshima... the charter wrangling
issue is whether a "2 browsers" constraint should go in the charter
as to why this shold be a WG... it's to get the middle of the
network.. proxies... cisco... to acknowledge this as legitimate to
address reliability issues

<masinter>
[43]http://www.ietf.org/mail-archive/web/apps-discuss/current/msg009
74.html

[43]
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00974.html

NM: what I wonder if what the TAG should do is... consider this
story...

<jkemp> [44]http://trac.tools.ietf.org/bof/trac/wiki/HyBi a good
resource

[44] http://trac.tools.ietf.org/bof/trac/wiki/HyBi

NM: [something about self description or not. scribe is lost.] media
types... following links... content negotiation to use same URI for
RDF and HTML representations so that's motivation for traditional
RESTful access...

<jkemp> Note:

<jkemp> A sentiment has been expressed that perhaps the HyBi group
should not try to pick a specific "winner" with regards to
selecting a single bidirectional protocol. Instead the group could
examine issues that exist for using the HTTP upgrade mechanism to
upgrade to an arbitrary bidirectional protocol and produce
recommendations for HTTP clients, servers, proxies and gateways
that would allow various protocols to be used, to evolved and to
compete for wide support.

<jkemp> from HyBi wiki

NM: however, sometimes [this other pattern?] is more appropriate.
the trade-offs are...

JAR: I expect this advice is already known by the relevant
communities

<DC:> [it's not at all clear to me that what websockets is for is
written down anyplace mere mortals should be expect to find]

TBL: even in non-RESTful cases, self-description is nice... e.g.
SMTP "explain"

NM: it's not clear to me that the community knows this stuff. I get
questions about how to think about such things. That's the main
value I get out of TAG findings

AM: in the Web Services world, there are at least a couple specs
that tell you how to do this: WS-notification, WS-eventing... those
are significantly more complicated; they have: subscribe, timeout,
unsubscribe... pub/sub

JK: I think this is much lower layer

AM: transport layer?

JK: yes

HT: NM, when you asked about the TAG's feelings on RESTful access...
I'm surprised you didn't mention the use of GET for something that
can do things

TBL:'UPGRADE' is a get-out-of-jail-free card -- it means the
semantics of the request are changed

HST Ah, ok

<timbl> GET /demo HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
WebSocket-Protocol: sample

<jkemp> ^sample is from
[45]http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-43

[45] http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-43

TBL: historically, I thought of UPGRADE for switching to X
windows... but are there other uses of UPGRADE?

JK: HTTPS

<jkemp> (^sample is from)

<jkemp> [46]http://www.ietf.org/rfc/rfc2817.txt

[46] http://www.ietf.org/rfc/rfc2817.txt

<masinter> Presently HttpCore provides support for HTTP CONNECT
method for establishing end-to-end tunnels across HTTP proxies as
specified in the RFC 2817. However, HttpCore currently does not
support 'Upgrade' / 101 (Switching Protocols) handshaking, which
does not seem as widely used by the common HTTP agents and servers
as HTTP CONNECT.

<masinter> [47]http://issues.apache.org/jira/browse/HTTPCORE-158

[47] http://issues.apache.org/jira/browse/HTTPCORE-158

<masinter> ISA Server does not support the Upgrade header. If a
client sends a request containing this header, it is ignored by
ISA Server. Both client and server will use standard protocols.

<masinter>
[48]http://technet.microsoft.com/en-us/library/cc302548.aspx

[48] http://technet.microsoft.com/en-us/library/cc302548.aspx

<ht> [49]http://issues.apache.org/jira/browse/HTTPCLIENT-751

[49] http://issues.apache.org/jira/browse/HTTPCLIENT-751

JK: The hybi activity seems to have started to document best
practices, because of perception that straight HTTP isn't meeting
the need.

<ht> 2008-02-11: "AFAIK, we're not supporting upgrade of a plain
HTTP connection to HTTPS. We only support dedicated https:
connections so far. HttpClient 4.0 should be flexible enough to
add support for protocol upgrades. "

<ht> [50]http://markmail.org/message/5zhsaxe3bnbd7cee

[50] http://markmail.org/message/5zhsaxe3bnbd7cee

JK: Additionally, the W3C Websocket work has been sent to IETF, but
there are others in IETF hybi who believe that websockets isn't the
best way to meet the need.

JAR: If there's this much activity, it sounds like maybe we should
table this for now.

JK: There's good stuff on their wiki.

DC: When the IETF is working on a charter, think to do is not to
wait.

JAR: Sounds like materials are there.

DC: Can't say.

LMM: if we like the idea of best practices work, we could give that
input now

JK: there are other proposals...

DC: I learned today about the message-oriented framing. That was
useful, thanks.. Use cases on first slide and issues was also
helpful, as was learning about status of WG. So, this was what I had
in mind.

<scribe> scribenick: DanC_

NM: when we hear about other mechanisms... has the implementation
train already left the station?

LMM: no... there's quite spirited discussion among representatives
from Opera, XMPP, Linden labs....

NM: but about browsers...

JK: I think there has been little, but it's starting.

NM: Net, net, would people retune e.g. Firefox impl?

DC: Yes.

<masinter>
[51]http://www.ietf.org/mail-archive/web/hybi/current/msg00559.html

[51] http://www.ietf.org/mail-archive/web/hybi/current/msg00559.html

HT: does the hybi wiki cite this among others?

JK: yes

<ht> [52]http://trac.tools.ietf.org/bof/trac/wiki/HyBi

[52] http://trac.tools.ietf.org/bof/trac/wiki/HyBi

<masinter> [53]http://trac.tools.ietf.org/bof/trac/wiki

[53] http://trac.tools.ietf.org/bof/trac/wiki

<masinter> [54]http://www.faqs.org/rfcs/rfc2324.html

[54] http://www.faqs.org/rfcs/rfc2324.html

<masinter> XXXX is based on HTTP. This is because HTTP is
everywhere. It could not be so pervasive without being good.
Therefore, HTTP is good. If you want good coffee, XXXX needs to be
good. To make XXXX good, it is good to base XXXX on HTTP.

[adjourn for break]

[resume from break]

HT: I hope to hear from LMM about the upcoming [Hybi] BOF

LMM: we could consider this a liaison activity... we expect ...
[pronoun overload; which "they"?]

<masinter> I'm intending to be at IETF meeting and hope to attend
HyBi BOF, but I don't have a commitment to do so, although I'm
interested in the topic personally.

TBL: seems to me people are doing roughly the right thing; I'd be
more motivated to act if it looked like they were doing something
wrong

LMM: it's encouraging that W3C working groups are taking protocol
work to IETF

action-301?

<trackbot> ACTION-301 -- John Kemp to review websocket protocol/api
motivation and brief TAG at Sep ftf -- due 2009-09-24 -- OPEN

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

[55] http://www.w3.org/2001/tag/group/track/actions/301

close action-301

<trackbot> ACTION-301 Review websocket protocol/api motivation and
brief TAG at Sep ftf closed

DanC: how about a similar session on web storage apis? Maybe I'll
twist arms in a break...

Naming Schemes

<ht> [56]http://www.ltg.ed.ac.uk/~ht/tag_persist/

[56] http://www.ltg.ed.ac.uk/~ht/tag_persist/

action-33?

<trackbot> ACTION-33 -- Henry S. Thompson to revise naming
challenges story in response to Dec 2008 F2F discussion -- due
2009-09-18 -- OPEN

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

[57] http://www.w3.org/2001/tag/group/track/actions/33

HST presents "Forever is a long time: Real persistence for the Web"

HT: with that, on to JAR's suggestion...

JAR: so take any competent repository administrator or librarian...
they're dealing with all sorts of strings, whether they start with
http: or doi: or otherwise... and on behalf of their users, they
keep track of what these things mean they're going to build or buy
or find a resolver... one choice of providers is ICANN/HTTP/DNS ...
this pattern will hold regardless of which URI scheme they are using

<masinter> need to be careful to talk about the service provider for
name resolution and the guarantee for being the authoritative
service for resolving the name

JAR: suppose the repository manager believes me when I say "you can
use HTTP URIs"... they'll be in the same situation as with urn: or
other syntactic forms, they'll be in the same position of
build/buy/find a resolver... could be a database, proxy, alternate
DNS, etc.

<masinter> I think i really understand this now and i'm frustrated
at not being able to explain it

<masinter> [58]http://larry.masinter.net/duri.html

[58] http://larry.masinter.net/duri.html

<masinter> is one proposed solution

JAR: so if they find some other resolver, they're doing something
that's not sanctioned by Web architecture; not using ICANN/DNS/http

[fixing a bug in ICANN/DNS/http doesn't seem like something "not
sanctioned by Web architecture"]

<masinter> the obtainer of a name gets a "name", but implicitly they
get some kind of service guarantee from a name service provider,
that for the period they have purchased, the name service provider
will tell other people that the name they are using means what the
original name obtainer meant

<masinter> the discussion Henry and JAR tell confuses who gets the
name, who makes the service guarantee, and who is looking up the
name and obtains the name resolution

<Zakim> DanC_lap, you wanted to offer that w3.org falling into the
hands of bad guys is analagous to a linnean animal name morphing
into a trademark for some megacorp

<masinter> using the "wayback" machine leaves open the question of
how far back you go

<masinter> AWWW looks at "meaning" from the wrong end of the
telescope. Meaning can't change based on operational behavior

DC: Not clear why the hypothesised situation would break WebArch

<masinter> if you get a linnean name, you get something from an
organization that offers a long-term name resolution service

<noahm> ... Over time browsers would migrate to new URIs for W3
namespaces

LM: another attempt to explain what I've tried many times... when
you get a name, you think you're getting something. But what you're
really doing is entering into an agreement with a provider who
offers the service of resolving a name

<masinter> [59]http://larry.masinter.net/duri.html

[59] http://larry.masinter.net/duri.html

LMM: [... trust me as an authority]. the urn: scheme delegates that
to [one place] and http: delegates via ICANN/DNS/etc. one idea I've
put some work into is to add a timestamp to a URI... duri means what
that URI meant in the given date the current practice in academic
citations for web pages is to note the date of access

<DanC> (the authority for the Linnaean names is the peer-reviewed
academic community)

<DanC> (which was once one of the few people would could get things
published.)

<jkemp> authority is not noted in the name itself

HT: well, let's please get back to evaluating the AWWW story about
naming and authority

NM: perhaps we should push harder on having some DNS names where
persistence is more guaranteed. e.g. a new root

<masinter> good papers in
[60]http://www.isr.uci.edu/events/twist/twist99/

[60] http://www.isr.uci.edu/events/twist/twist99/

HT: the "more persistent DNS names" idea is good, but making the
domain name/owner binding stronger doesn't amount to a guarantee
that it's perfectly strong

<Zakim> timbl1, you wanted to say one can always make a different
resolver for http uris so long as it doesn't misrepresent -- so long
as it doesn't give wrong data, where right data is

NM: [missed some subtlety about the stronger DNS idea]

<masinter> AWWW is wrong because [61]http://www.w3.org/anything
means "open HTTP connection to www.w3.org and ask it about
"/anything". If you want something else you need "tdb", it's not
optional

[61] http://www.w3.org/anything

<masinter> and it doesn't matter how much you wish anything else

<noahm> I was noodling on the possibility that the guarantee would
be such that W3C or anyone else "owning" a DNS name would have
complete control over lines of succession for it.

TBL: JAR, there are lots of times when people know what an http URI
name means without doing an http lookup; that's fine as long as it's
not inconsistent with what you'd get if you did a lookup

<Zakim> timbl2, you wanted to suggest that extreme scenarious make
bad design. Extreme situations occur with other things -- librraies
with species in can get hacked, and specifically

<masinter> the leap of faith needs to be explicit

JAR: I'm talking about people using resolvers that are inconsistent
with what you'd get with a lookup; e.g. OpenDNS resolves DNS names
that normal DNS doesn't

TBL: starting with a screw case doesn't make for a good argument.
The case of W3C losing w3.org is uninteresting.

TBL: The Commerce Department will take domain names by eminent
domain

TBL: HT started by saying the Linnaean name system works great, but
of course somebody could replace all the books in the library to
screw it up.

<Zakim> timbl3, you wanted to say that in fact in a less wildy
extreme scenario, in fact there is n serious value in pursuing more
persistent domain names which the TAG could follow up

<masinter> 'meaning' is a verb, not a noun. a URI producer 'means'
something and a URI consumer attempts to discover what the URI
producer meant. To define 'meaning' as a noun in AWWW confuses these
things. We're asking producers to have faith that http: URIs to mean
what they want to mean, in order that future consumers can readily
discover their meaning.

<DanC> (HT, recall that I pointed out that the URI would slowly
degrade if the divergence between the software and the server at
w3.org disagreed.)

<noahm> (DanC, I'm not so sure -- why? Everything would continue to
work if both browsers and users continued to use it as the NS URI)

<DanC> (because people would not want to be associated with what the
bad guys publish there)

<jar> timbl: New TLD for use e.g. for persistent http:

<noahm> ACTION Noah to schedule discussion of a persistent domain
name policy promotion

<trackbot> Created ACTION-311 - Schedule discussion of a persistent
domain name policy promotion [on Noah Mendelsohn - due 2009-10-01].

<DanC> ("permanent names" is a category error. as LMM points out,
the request is for "permanent services" which is clearly absurd.)

<Zakim> timbl4, you wanted to point out that this is a question of
trust, and trust has a lot of Not Invented Here to it, and many
people will trust something when and only when they have been
seriously

TBL: the actual case in the lifesci community is about trust...
somehow they trust the LSI committe but not ICANN...

<masinter> [62]http://www.isr.uci.edu/events/twist/twist99/
"problems URIs don't solve"

[62] http://www.isr.uci.edu/events/twist/twist99/

TBL: maybe if they'd been on the ICANN committee they'd trust them
more... or if they'd been involved in HTTP [ESPEAKINGTOOFAST. bzzt.]

LMM: I think AWWW/webarch is wrong because it makes an implicit leap
of faith which needs to be explicit...

<timbl> You can by the way bind the persistence not to an
organization but to content (or meaning if you can define that)

LMM: the step of opening up a connection is implicit... and this
leads to contradictory conclusions

<DanC> (it spells out that stuff a few sections lower)

<jar> there are no guarantees

LMM: if I write a URI in a book, and [something changes] it doesn't
change the meaning of the book. Permanent names don't solve the
problem that they're hoped to solve... financial failures etc. ...
you come to the conclusion... that alternatives are no better than
http

LMM: and in cases like doi and [missed], they're in a commercial
position that we're in no position to argue down

<DanC> (lmm, sorry, I'm afraid I mangled what you said)

<Zakim> jkemp, you wanted to note that Linnaean names don't contain
an authority

JK: Linnaean names have the feature that resolution isn't part of
the name... I can use google...

<jkemp> neither resolution nor (any statement about) authority are
included in Linnaean names

<jar> actually careful biologists will specify the last name of the
author of the authoritative publication...

<masinter> implicitly 'search' becomes the naming system; it's a
problem with folksonomies

<DanC> huh? resolution is involved any time anybody utters a
Linnaean names and hopes somebody to understand

<Zakim> DanC_lap, you wanted to note persistence guarantees mostly
come from either $$/lawers or rich social networks/communities

DC: The way you get persistence is either by protecting it with $$$
or with a large distributed community. IETF is a good example.
Persistent names is a category error, not persistence names, but
persistence services and persistent services are absurd. Endowed
publication is a great idea

TBL: UK gives special status to e.g. the National Trust -- you can't
get their land off them w/o an act of Parliament

HT: yes, Tim, you're right, hard cases make bad law... but certain
constiuencies are obligated to consider the hard cases... these
scholarly edition communities and lifescience identifiers
communities can't avoid it this (2.2.2.1. URI ownership) is all
webarch says about how URIs get their meaning

DanC: no, there's another section on how to resolve URIs

HT: but that says nothing about meaning

<jar> I think how to resolve is not the issue

DanC: see the intro, on the relationship between representations,
URIs, and resources

<jar> (discussion of authority. is there a bug in awww.
disagreement.)

LMM: I disagree that the owner determines the meaning of the URI...

<noahm> LMM: A URI does not lose its meaning because a service
provider fails to deliver on their contractual obligation

<noahm> (HST, e.g. with respect to resolving the domain name part)

JK: You can type the URI into google

DC: Consider the way phone numbers work -- if you stop paying for
your phone, its number will eventually get recycled to call someone
else

<Zakim> jar, you wanted to talk about GBIF WG solution

LMM: It should say that if the ISP misbehaves the meaning of a URI
doens't change. Tim: When we define a protocol, we say that if
everyone obeys these rules, these are the good properties which
result. We don't address normally what happens if you don't obey the
rules.

<Zakim> masinter, you wanted to give some references to twist99
talks and to disagree that the owner of the domain is the
"authority" to determine what the URI "means"

jar: the GBIF task force on identifiers decided that http URIs can
be considered persistent, with alternative resolution option as an
insurance policy against domain name loss. is this approach
consistent with AWWW and the RFCs?

<DanC_lap> [... and that little clause, even if it never happens,
allows these communities to buy in.]

<Zakim> DanC_lap, you wanted to note that IMGT allele names are
being revised this year; things change; these communities deal

<jar> (noting that the GBIF folks tried out urns, and couldn't make
them work... not necessarily through any fault of their own)

DC: You have to get people to use names to get them to mean
anything. Speaking of hard cases the IMGT community are deciding to
change all their names

JAR: They are ill-advised

<DanC_lap> ("the way"? it's an important way... a distinguished
way... but not "the way")

<jar> noahm: usually you poke on something's URI to find out what it
is, but this doesn't always work. you have to reverse engineer
sometimes

NM: If I have a URI which identifies a webcam view of my back door.
If someone else looks at it five nights running, they will
legitimately conclude that my URI identifies a blank page

<jar> (LRDD would be the way you communicate what it's supposed to
mean)

NM: The only definitive way to find what a URI means is to go to the
owner and ask them

LM: No, that's just wrong -- AWWW is broken insofar as it says that

NM: [gives an example, scribe missed]

LM: Scenario 1: I give you a URI. Scenario 2: I give you a URI, but
I tell you at the same time that the URI identifies a piece of
paper, which I hand you. In scenario 2, the URI is useless

JAR: W3C specs are full of this -- they say "This URI means...."
without any necessary correlation with what you get with GET

TBL: Do you mean, e.g., OWL spec says this that and the other are
properties what's wrong with that?

LM: [put a document in a drawer -- scribe didn't catch]

DC: Can I assign meaning to numerals?

LM: You can't -- you can only tell me what you mean by them

JK: We've established community consensus that 23 comes after 22

DC: I give up

HT: I'd like to pick that up sometime

LMM: yes, I've been looking forward to this conversation

HT: Wrapping up... I'd like to come back to this sometime... I've
heard some endorsement of the claim that webarch is incomplete/wrong
on how URIs get and retain meaning...

NM: any other concluding remarks?

LMM: I think trust/belief are important... this conversation where
Dan was getting frustrated... I think he was saying things that
seemed obvious and I wasn't agreeing because he was leaving out
subjects/objects.

<jar> dan likes the succession clause (see my comments above about
GBIF)

DanC: my take-away is that this succession [sp?] clause is
interesting... the fact that it allows people to get on with it
seems great.

NM: the idea about more-permanent DNS names seems interesting...
also, this idea that you can discover resource meaning by
experiment... that it only sometimes works is interesting

action-33?

<trackbot> ACTION-33 -- Henry S. Thompson to revise naming
challenges story in response to Dec 2008 F2F discussion -- due
2009-09-18 -- OPEN

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

[63] http://www.w3.org/2001/tag/group/track/actions/33

HT: I don't think this is higher priority than review of HTML, but
I'd like to get back to it

<scribe> ACTION: jar to find a path thru the specs that I think
contradicts Dan's reading of webarch [recorded in
[64]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action04]

[64] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action04

<trackbot> Created ACTION-312 - Find a path thru the specs that I
think contradicts Dan's reading of webarch [on Jonathan Rees - due
2009-10-01].

<jar> (the topic of how to find out what resource is meant has come
up twice in this conversation, from noah and from ht - the idea that
doing GETs is not adequate to find out what it is. ashhok and jar
chant 'LRDD')

<jar> (and i think this orthogonal to the main conversation)

Adjourned until tomorrow

Summary of Action Items

[NEW] ACTION: Henry S. to bring back proposed TAG pushback on
sniffing and HTTP bis draft
[65]http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf
-httpbis/latest/p3-payload.html, or his recommendation that we leave
it alone [recorded in
[66]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action02]
[NEW] ACTION: jar to find a path thru the specs that I think
contradicts Dan's reading of webarch [recorded in
[67]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action04]
[NEW] ACTION: John to propose updates to Authoritative Metadata and
Self-Describing Web to acknowledge the reality of sniffing, due
2009-10-20 [recorded in
[68]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action01]
[NEW] ACTION: Noah to check with Sam Ruby on ECMA/W3C activities at
TPAC [recorded in
[69]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action03]
_________________________________________________________

[65]
http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html
,
[66] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action02
[67] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action04
[68] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action01
[69] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action03

Minutes formatted by David Booth's [70]scribe.perl version 1.134
([71]CVS log)
$Date: 2009/09/29 10:53:15 $

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

[1]W3C

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

- DRAFT -

TAG F2F day 3 -- 25 Sep 2009

25 Sep 2009

See also: [2]IRC log

[2] http://www.w3.org/2009/09/25-tagmem-irc

Attendees

Present
jar, masinter, noahm, DanC, noah, TimBL, ht, johnk, raman

Regrets

Chair
Noah Mendelsohn

Scribe
Ashok Malhotra, Jonathan Rees

Contents

* [3]Topics
1. [4]HTML Issues
2. [5]HTML
3. [6]HTML Data Facilities
4. [7]TAG admin (TPAC logistics, future meetings)
5. [8]TAG priorities
6. [9]HTML issue: text/html mime type
7. [10]Geolocation/Geopriv
* [11]Summary of Action Items
_________________________________________________________

<Ashok> scribe: Ashok Malhotra

<Ashok> scribenick: Ashok

Noah: reviews the agenda
... I would like to spend majority of our time on HTML
... skip TAG Priorities
... Let's do admin right after lunch

Jar: Let's ask people what they are gonna do

Noah: Let's use Action Item list

HTML Issues

HTML

Noah: What should be next topic for discussion

Larry: I thought were close to consensus on sniffing

Noah: Let's do it on a telcon

Larry: I think we could come up with a position on it.

HT: I have action to propose pushback or accept status quo

Noah: Who wants to discuss sniffing now?

<DanC_lap> action-309?

<trackbot> ACTION-309 -- Henry S. Thompson to s. to bring back
proposed TAG pushback on sniffing and HTTP bis draft
[12]http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf
-httpbis/latest/p3-payload.html, or his recommendation that we leave
it alone -- due 2009-10-01 -- OPEN

[12]
http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html

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

[13] http://www.w3.org/2001/tag/group/track/actions/309

HT: My inclination is to ask them for a health warning

Larry: I would like to discuss for 10 mts

Poll 3 to 1 ... not now

Noah: What next item to discuss

DC: Data facilities

HT: I would like to report what I found out wrt item 13

HT to give 3 minute report on item 13

HT: I took the binary attribute case

Tim: Boolean

HT: I explored that whereever there was an error there should be
error recovery case
... I sent mail and was told "No, what you say goes in the DOM"

<DanC_lap> (ht, did you say "it's all in public-html"? I don't see
it in
[14]http://lists.w3.org/Archives/Public/public-html/2009Sep/thread.h
tml )

[14]
http://lists.w3.org/Archives/Public/public-html/2009Sep/thread.html

HT: Reason is -- this is an extensibility point

<DanC_lap> (false advertising. this is discussion. not
clarification)

Larry: Is input disabled or is it not?

<DanC_lap> ah... found it: Where is processing of binary attributes
covered? Henry S. Thompson (Wednesday, 23 September)
[15]http://lists.w3.org/Archives/Public/public-html-comments/2009Sep
/0064.html

[15]
http://lists.w3.org/Archives/Public/public-html-comments/2009Sep/0064.html

HT: It IS disabled
... Binary attributes are true if present, false if not present

Larry: So, disabled = false results in TRUE

HTML Data Facilities

Tim: 2 overlapping concerns --- how should data be handled in HTML,
--- overlap with extensibility of tags
... it's important to put RDF into HTML
... RDFa spec tells you how to do that.
... Hixie said removing namespaces was a goal, and it's hard to use
RDFa without namespaces.

Noah: Shall we separate extensibility concerns?

Tim: I'm happy to discuss microdata and Hixie's special data format

<jar> 'rdfh' ... I'd like to hear more about this

Tim writes on board --- RDF in HTML, RDF, microformats,
Data-Attributes, ---- no NS in HTML, Extension Tags

Tim: These are various positions people have taken

<noahm> We are using the queue

<noahm> I think

jar: Has anyone articulated that you might do RDF in HTML w/o
namespaces?

DC: There is a proposal

<jar> the answer was: Yes, data-... does RDF in HTML, but only an
(albeit useful) subset.

Tim: Some say don't bother with namespaces; others say give me the
namespaces tool

<DanC_lap> TBL: the blobs [in the whiteboard diagram] are positions;
the x's are issues.

Larry: HTML5 now has a data format based on no known experience

DC: No deployment of the data stuff

<DanC_lap> blobs = RDF in HTML, RDFa, Need NS in HTML, microformats,
data-*, No NS in HTML, Extending Tags

jar: You could extract triples from data-attributes

DC: That code has been written

Discussion about whether data- or item-property

Noah opens HTML spec

DC: 5.2 Microdata

<DanC_lap>
[16]http://dev.w3.org/html5/spec/Overview.html#encoding-microdata
5.2 Encoding microdata

[16] http://dev.w3.org/html5/spec/Overview.html#encoding-microdata

<DanC_lap>
[17]http://dev.w3.org/html5/spec/Overview.html#custom-data-attribute
3.2.3.8 Embedding custom non-visible data

[17] http://dev.w3.org/html5/spec/Overview.html#custom-data-attribute

DC: Custom data attributes: 3.2.3.8

Noah: What is difference between data- and the item stuff
... if you do data- you get a Javascript object with that name

DC: What's the motivation?

Noah: Extends that data space for Javascript programmers

HT: It's a way of extending attribute space
... The para after the note is the justification

Noah: How [?] different from item-
... is there a glimmer of a comment here?

JK: There may be another position --- no NS mapping rather than no
NS

Noah: There is third position ... just use short names and handle
collisions

Tim: The item- maps to a URI

JK: Section 5.1.3 in WHATWG spec
... says "As URLs"

Larry: This section is non-normative

Tim: This is a competing proposal to RDFa
... subject is where it is attached to

Looking a frag in 5.1.2

Tim: Item property can be a URI or a reverse domain name thingie

Noah: Both data- and item overlap with RDFa
... could extract RDFa from this

jar: That is not a usecase

<Zakim> johnk, you wanted to note that I believe "no namespace
prefix mapping" is more accurate than "no namespace"

Discussion on whether RDFa can be represented in this form

Tim: Go to 5.1.4 and look at example
... 2 properties of Hedral

JK: Section 5.2.3
... Associating names with Items

HT: In 5.1.1 near the end --- properties don't have to be given as
descendents of the element with item attribute
... They can be associated with a specific item using the itemfor
attribute which takes the ID of the element with the item attribute

DC: There is a well-known pattern for licenses for images. Is that
expressible in this syntax.

<timbl> [18]http://dev.w3.org/html5/spec/microdata.html#overview

[18] http://dev.w3.org/html5/spec/microdata.html#overview

HT: Properties that also have values that are URLs. This is achieved
by using the a element and the href attribute, ....

Tim: 5.5.2 RDF ...

<ht> Looks to me that <img src="....." item /> <div style="display:
hide"><a href="xxxxx" itemprop="[CCREL]"></a></div> will do it

Tim: We could make a comment about the process

<Zakim> ht, you wanted to ask about <script
type="text/rdf+xml">...</script>

HT: Minor aspect of script which says the script item is used to
introduce script or data ... type of data is given by type attr of
script

<Zakim> noahm, you wanted to say, I claimed this stuff was related
to GRDDL more than RDFa and to

HT: does not say what you can do with the data

<jar> ben a: " it makes things much more roundabout to write since
itemprop applies to both (either?) @href and the element content"

HT: The item I put in IRC log will do what jar asks
... I left out the ID and the item4

<ht> <img src="....." item id="photo7" /> ... <div style="display:
hide"><a href="xxxxx" itemprop="[CCREL]" subject="photo7"></a></div>

Tim: Critiques the algorithm

<ht> more recent draft uses 'itemfor' for 'subject'

Tim: There is incredible tension between communities expressed on
the board
... TAG could perform useful function.
... is it functionally equivalent to RDFa, or not?

<DanC_lap> ht, we could try out the example you made...

<DanC_lap> [10:17] <Philip> DanC_lap:
[19]http://philip.html5.org/demos/microdata/demo.html ?

[19] http://philip.html5.org/demos/microdata/demo.html

<DanC_lap> [10:18] <Philip> Also
[20]http://james.html5.org/microdata/

[20] http://james.html5.org/microdata/

Larry: I'm concerned about us not driving to statements

<DanC_lap> [10:17] <Philip> DanC_lap:
[21]http://philip.html5.org/demos/microdata/demo.html ?

[21] http://philip.html5.org/demos/microdata/demo.html

<DanC_lap> [10:18] <Philip> Also
[22]http://james.html5.org/microdata/

[22] http://james.html5.org/microdata/

Larry: I have a process suggestion
... create statements and choose between them

DC: That may be helpful

Larry: 10 minutes to solicit things we may say

<noahm> JAR: One thing we might say [straw man] is: "HTML has to
adopt namespaces and RDFa" (not sure I believe that, but it's one
thing we might want to say)

<jar> or reject

<DanC_lap> LMM: I see no justification for reverse domain name
labels where URIs would solve the problem

<DanC_lap> tbl 2nds

Larry: No justification for introducing reverse domain-based
namespace mechanisms are adequate

<DanC_lap> s/are allowed/are adequate/

<jar> (jar was confused by 'reverse DNS' - I think what's meant is
"reversed domain names" and is not related to reverse DNS lookup)

Tim: RDFa and item- are almost identical functionality
... so they create fragmentation which is always damaging

<johnk> Notes:
[23]http://www.balisage.net/Proceedings/vol3/html/Quin01/BalisageVol
3-Quin01.html on "automatic XML namespaces"

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

HT: Introducing a new unimplemented and untried design where there
is an implemented tried design is not helpful

<Zakim> DanC_lap, you wanted to say we might say that RDFa should
have no special status just because it's a REC, since W3C allowed it
to go thru CR without coordination with HTML 5

<jar> is there a requirements statement for item, itemprop etc? is
rdf capture a requirement? where articulated?

Noah: The item- is simpler syntactically ... I'm half-convinced
about this

<johnk> ... and
[24]http://lists.xml.org/archives/xml-dev/200907/msg00157.html
"pragmatic XML namespaces"

[24] http://lists.xml.org/archives/xml-dev/200907/msg00157.html

Noah: not enough justification for duplication

<DanC_lap> (re "would anybody use microdata?" there's a relevant
thread at
[25]http://lists.w3.org/Archives/Public/public-html/2009Jun/thread.h
tml#msg732 )

[25]
http://lists.w3.org/Archives/Public/public-html/2009Jun/thread.html#msg732

Tim: RDF is REALLY simple
... first notation for mapping RDF to XML was really complicated

<johnk> "How to make namespaces in XML easier":
[26]http://ln.hixie.ch/?start=1151612438

[26] http://ln.hixie.ch/?start=1151612438

<noahm> I heard Tim say the opposite; I heard him say RDF as a model
is inherently very simple, but RDFa (and also RDF/XML) is
suprisingly complicated

Tim: there is a lot of parser state to be carried along

<ht> s/RDFa is simple/RDF is simple/

<noahm> For those curious about my "Tim said the opposite" comment,
our scribes used log edits to fix what Tim said. I do not believe
said the opposite of the fixed comment.

<timbl> ... aka /opposite/d

BREAK till 10:50

<timbl> I said that RDF/XML was surprisingly complicated, people
saying that that came from its attempt to look like "colloquial
XML"; that we had a few other attempts at syntaxes, including N3,
and then in *ML again we had RDFa, maybe the fourth, which to me was
surprisingly complicated, involving a surprising amount of state to
be held by the parser duriung its recursive descent, and now we have
RDFb (lets call it) whcih attempts the same thing, and again is
surprisingly

<timbl> complicated when you look at the algorithm. Is there a
fundamental difficulty to this challenge?

JK: I pasted a link about distributed extensibility above

<noahm> Chair notes that we are filling some time talking about
proposals that are floating around for namespace-based extensibility
until Tim gets back.

JK: there are other proposals: Liam Quin and Tim Bray's delta on
Micah Dubinko's proposal

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

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

<noahm> JK: First proposal is Balisage proposal from Liam Quin

<masinter> references include pointer to
[28]http://ln.hixie.ch/?start=1151612438

[28] http://ln.hixie.ch/?start=1151612438

HT: This says we are going to associate NSs with some elements. Does
away with prefixes

DC: There is some outboard doc that gives the mapping

HT: Processors will bake in a version of the doc they support

Noah: Some will be baked in, others [specified] in an outboard doc

DC: Does this work like static scoping?
... if elements indicate namespaces then it's like static scoping

<johnk> xml-dev collated proposal
[29]http://www.dpawson.co.uk/namespaces/index.html

[29] http://www.dpawson.co.uk/namespaces/index.html

JK: This where the thread that Micah started ended up ... this has
notion of reverse domain syntax
... Micah's email

<johnk>
[30]http://lists.xml.org/archives/xml-dev/200907/msg00157.html

[30] http://lists.xml.org/archives/xml-dev/200907/msg00157.html

HT: This is too disruptive, so it's a non-starter

Noah: Do we continue on Data Facilities? or move to other topics?

<Zakim> DanC_lap, you wanted to say that complexity for the parser
is often anti-correlated with complexity for the author

<Zakim> danc2, you wanted to ask who are the daily minutes-editors

DC: There are 2 kinds of complexity: for authors and for parser
writers

Tim: If it's hard to write the parser it's hard for authors

<noahm> In about 7 minutes, which will be ~ halfway through, I will
stop discussion to see if we are closing in on next steps.

<jar> danc: Syntactic sugar and defaults make authoring easier but
parsing harder

Discussion about syntactic sugar

Tim: 2 pieces --- triples and triple state

<DanC_lap> TBL: both [sorts of complexity] make learning the
language harder

<masinter> and also that 'data' and 'metadata' are really the same

DC: Do users grok or not .... people pick up RDFa and use it. People
don't use microdata

<masinter> and also that i think the charter of the group and the
right answer is that neither RDFa nor data should be part of HTML
spec and are out of scope for group's charter, group was charatered
to produce extensibility

Larry: HTML WG was not chartered to do any of this work .... this
ought to be out of scope
... area should be able to evelove independently from the HTML
language

<timbl> [31]http://www.w3.org/TR/rdfa-syntax/

[31] http://www.w3.org/TR/rdfa-syntax/

Larry: HTML is not usually written by humans; it is generated from
database tools
... complicated tool chains
... one of the proplems with NSs is that NS-based markup does not
cut and paste well

<Zakim> masinter, you wanted to talk about complexity for tools for
generating, ability to mash-up, ability to copy-paste

<masinter> without moving to dom

<Zakim> danc3, you wanted to note complexity discussion currently

DC: There are various threads about complexity of HTML5. Opportunity
to get involved in current discussion

<Zakim> johnk, you wanted to ask Larry if he thinks that's true with
XHTML changes

<DanC_lap> Complexity of HTML5 (was Re: The Complexity Argument)
Maciej Stachowiak (Sunday, 20 September)
[32]http://lists.w3.org/Archives/Public/public-html/2009Sep/0814.htm
l

[32]
http://lists.w3.org/Archives/Public/public-html/2009Sep/0814.html

JK: Asks about charter? Should it still be true given that XHTML is
winding down.
... there are specific needs to do the extensibility

<Zakim> DanC_lap, you wanted to note sympathy with the "add an
extensibility mechanism, not RDFa nor microdata directly" position;
GRDDL was based on the head/@profile extensibility

Larry: W3C should charter a group on Metadate .... how to add
Metadata to HTML

DC: Talks about GRDDL as an example

Tim: Are people using GRDDL?

<johnk> DC: notes that GRDDL extensibility is achieved by use of the
HTML profile attribute

JAR: There are (this is irrelevant) XSLT that parse RDF/XML and
produces triples

DC: Community not supporive of my suggestions on extensibility

Tim: Talk about problem with cut/paste of NS-based markup

<Zakim> timbl, you wanted to say that to have a de-prefixed from for
cut and paste woul dbe reasonable.. this works with attributavalues
abut not alas with element names. You can for

Tim: Are there oher reasons why people do not like Namespaces

Noah: We need an Action

<timbl> More generally, to get more arcs in a motivation graph to
elaborate what is on the whiteboard.

<DanC_lap> timbl, another rationale behind the the "no URI prefix"
position is: what happens when you mutate the DOM?

Larry: The HTML WG has pointed out a flaw in XML and we should puch
back on XML's syntax on Namespaces
... TAG could encourage re-examination of Namespaces

<Zakim> noahm, you wanted to try and focus discussion and to talk
about exploring namespaces

Noah: Some sympathy but efforts like that may fail
... suggests some TAG action
... Should TAG analyze the situation?

Larry: The TAG could endorse ongoing work outside and encourage a
W3C activity to look into revising Namespaces

HT: What is the flaw in XML which HTML has called attention to?

<timbl> DanClap, re "no uri prefix" a reasonable position is that
the prefix is just a shorthand, and the DOM is the data model, so
the DOM should have the full URI. (Like the RDF model does). It is
then a serialization option as o whether you se a prefix shorthand.

Noah: Problems with Namespaces ... cut and paste problems, typing
stuff with namespaces turns out to be harder than typing stuff
without

<Zakim> ht, you wanted to ask LM to expand on "HTML requirements"
for XML namespace design

DC: DOM modifications

JK: Sympathetic to Larry's proposal but we need to do our homework.
We should speak to people at Balisage.

Noah: Tries to clarify proposals

HT: We misunderstood Larry use of the word "endorse".

Noah: We need to do homework first

Tim: Reminded of Cambridge Communique time

Noah: Need specific actions

Larry: We could ask XML Core to do some homework

HT: This would require a charter change

Noah: Worries about skill set. Needs knowledge of use of Namespaces
in different contexts

HT: Flaws in XML are not addressed by any of these proposals

<johnk> HT: I heard two proposals - i) propose changes to XML Core
ii) bring together HTML and XML folks to make a namespace proposal
acceptable to both

HT: Requirements did not have anything to do with HTML

Larry: HTML WG found that current XML infoset serialization is too
difficult for them.
... we should examine what infoset would meet their needs and also
allow distributed extensibility

<masinter> there is precedent for W3C working on alternative
serializations of XML

Larry: This is not a short-term comment to HTML WG. There is some
long-term work that W3C should take up to prevent communities from
forking off

<masinter> this isn't the 'solution', but I am very concerned about
W3C endorsing two separate forks of HTML on the one hand and XML on
the other, and that perhaps this is 'research', but that the TAG
should lead effort toward convergence

<masinter> i don't want the default answer to be "oh well, i guess
they're different, let's just leave them going off in different
directions"

Tim: XML Model, HTML model and RDF model is a triangle. Trying to
harmonize may be a mistake. Should be arms-lenghth relationship
... Narrow the scope to attribute values, not attribute or element
names

Noah: Please type possible actions into IRC log

<johnk> I am suggesting that I talk to those who went to Balisage,
and ask what was discussed regarding the namespace-focused work
there, and report back to TAG

<timbl> In other words like microdata and RDFa, use the *ML DOM as
it is and putthings in the attribute values.

<DanC_lap> maybe invite advocates of a few of the positions tbl put
on the board (see "blobs" above) to a TAG meeting to discuss them.

<timbl> +1 to JohnK anyway

<masinter> i suggest johnk also float the idea of further work
specifically on this, and that we ask also HT to explore the
questions with XMLCore

<masinter> i suggest the tag also put out a position that we would
like to see work in this area

<noahm> Larry offers to take action to draft message that the TAG
will endorse

<masinter> possibility of coming up with a new serialization of
infoset, which would be acceptable to HTML community, please explore

HT: Larry phrased a new serialzation of the Infoset . I can ask
XMLCore. Asking them to chamge XML would be much more contentious

<masinter> "please ask the XMLCore group what in the area of
discovering and meeting HTML's requirements they would be willing to
do, and what prerequisites they would have for doing it"

<masinter> i propose Henry do what I just typed

Noah: Will you take an action to come back to TAG with a proposal
for whether and how TAG should interact with XML Core re. Infoset
serialization

HT: I don't know what HTML's requirements are

Tim: Too vague ....

HT: I will think about that

<johnk> ACTION: John to talk to Balisage participants about XML
namespace work, discuss TAG interest in this area, and summarize
recorded in [33]http://www.w3.org/2009/09/25-tagmem-irc]

[33] http://www.w3.org/2009/09/25-tagmem-irc

<trackbot> Created ACTION-313 - Talk to Balisage participants about
XML namespace work, discuss TAG interest in this area, and summarize
[on John Kemp - due 2009-10-02].

DC: Any volunteers to get the concerned players together?

JK: I can ask the Balisage players

<johnk> DC: That's not who I meant

HT: No, the players for the consitituencies on the board

Suggestions - invite Ben Adida, Manu

Larry: Possibility of meeting at TPAC?

BREAK for LUNCH

Reconvene at 1:15 PM

<jar> scribe: Jonathan Rees

<jar> scribenick: jar

dan does wed cleanup

ht does thu cleanup

jar does fri minutes cleanup

noah will collate / link all minutes

Reconvening.

<ht> TV, dial in to discuss next meeting, please?

<ht> Raman?

<ht> T.V.?

<timbl> People in the room wave to Raman.

noah: admin review. note, membership is turning over a bit

ht: All please think about who should stand for membership

TAG admin (TPAC logistics, future meetings)

noah: Future meetings: TPAC and Dec 8-10

Dec 8-10 will be at MIT again

<DanC_lap> (anybody want to offer, here in IRC, to host a meeting?
at least tentatively?)

After that: An idea: co-locate TAG and IETF, Anaheim, March ?

AC meeting is at MIT Mar 21-23

Mar 21-23 is Sun-Tue. LM proposes TAG just before that

scribe: more discussion of meeting planning ...

Noah: MIT Mar 17-19 ?

ashok: too early to tell

(no one is saying they can't make that)

Passed - subject to possible future modification - but for now let's
plan on MIT Mar 17-19

RESOLUTION: TAG F2F, MIT, Mar 17-19

<scribe> ACTION: noah Check with Amy on room availability and
suggest to Ian that he mention this meeting in TAG election call for
nominations [recorded in
[34]http://www.w3.org/2009/09/25-tagmem-irc]

[34] http://www.w3.org/2009/09/25-tagmem-irc

<trackbot> Created ACTION-314 - Check with Amy on room availability
and suggest to Ian that he mention this meeting in TAG election call
for nominations [on Noah Mendelsohn - due 2009-10-02].

<noahm> Who will be @ TPAC?

<noahm> Henry, Dan, Ashok, Larry

<noahm> TPAC regrets: John and Jonathan and Tim

noahm: We will meet Mon am, Fri am; available to meet with other WGs
at other times

noah: We used to have TAG progress reports, that stopped at some
point, any interest now? (probably not)
... Any WGs we want to reach out to?
... The meeting at plenary in France was really good

<scribe> ACTION: DanC to follow up on best plan for HTML / TPAC
recorded in [35]http://www.w3.org/2009/09/25-tagmem-irc]

[35] http://www.w3.org/2009/09/25-tagmem-irc

<trackbot> Created ACTION-315 - Follow up on best plan for HTML /
TPAC [on Dan Connolly - due 2009-10-02].

<amy> i confirm I've reserved space for 17 March in G449 (Kiva); 18
March in room 346 (Kiva and Star were not available) and on 19 March
in G449 (Kiva)

<ht> Amy ++

DanC: Re ECMA, Sam suggested Friday, but there was a conflict

noah: Meet separately with ECMA folks?

lm: primary discussion around ecma is around process, as much around
technical work. we can make ourselves available of course

action-310

<DanC_> action-310?

<trackbot> ACTION-310 -- Noah Mendelsohn to check with Sam Ruby on
ECMA/W3C activities at TPAC -- due 2009-10-01 -- OPEN

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

[36] http://www.w3.org/2001/tag/group/track/actions/310

TAG priorities

sort actions by owner

<DanC_> action-116?

<trackbot> ACTION-116 -- Tim Berners-Lee to align the tabulator
internal vocabulary with the vocabulary in the rules
[37]http://esw.w3.org/topic/AwwswDboothsRules, getting changes to
either as needed. -- due 2009-08-01 -- OPEN

[37] http://esw.w3.org/topic/AwwswDboothsRules

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

[38] http://www.w3.org/2001/tag/group/track/actions/116

<DanC_> action-116 due 1 Dec

<trackbot> ACTION-116 Align the tabulator internal vocabulary with
the vocabulary in the rules
[39]http://esw.w3.org/topic/AwwswDboothsRules, getting changes to
either as needed. due date now 1 Dec

[39] http://esw.w3.org/topic/AwwswDboothsRules

Timbl: It's good to be reminded of it

<DanC_> close action-24

<trackbot> ACTION-24 clarify [40]http://www.w3.org/2003/04/iri ,
perhaps by using N3 closed

[40] http://www.w3.org/2003/04/iri

timbl: (refers to new IRI spec drafts)

<DanC_> action-24: withdrawn in Cambridge. TBL suggests LMM consider
stuff in this area

<trackbot> ACTION-24 clarify [41]http://www.w3.org/2003/04/iri ,
perhaps by using N3 notes added

[41] http://www.w3.org/2003/04/iri

lm: The new drafts should not influence whatever action is implied
by this action item

timbl: Would like to drop it.

<DanC_> close action-24

<trackbot> ACTION-24 clarify [42]http://www.w3.org/2003/04/iri ,
perhaps by using N3 closed

[42] http://www.w3.org/2003/04/iri

Dan's actions:

ACTION-307?

<trackbot> ACTION-307 -- Dan Connolly to raise issue of work items
moving between W3C working groups and also with IETF -- due
2009-09-30 -- OPEN

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

[43] http://www.w3.org/2001/tag/group/track/actions/307

lm: This is a process issue, I don't think it's finished
... Hypertext coordination group might take this on?

danc: If I don't get this done today I don't want to carry it

action-299?

<trackbot> ACTION-299 -- Dan Connolly to notify the TAG when the
HTML WG gets closer to closing issue-4 html-versioning -- due
2009-09-10 -- OPEN

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

[44] http://www.w3.org/2001/tag/group/track/actions/299

<DanC_> action-299 due 15 Oct

<trackbot> ACTION-299 Notify the TAG when the HTML WG gets closer to
closing issue-4 html-versioning due date now 15 Oct

action-295

action-295 due is 1 week

<trackbot> ACTION-295 Monitor geolocation response to IETF GEOPRIV
comments on last call and report to the TAG due date now is 1 week

danc: Discussion is out of order
... of the actions that is
... (Generally, not action) HTML validation software dev work that I
might do

(danc was addressing JAR's request to hear from everyone re tag work
they planned for this fall)

action-308?

<trackbot> ACTION-308 -- John Kemp to propose updates to
Authoritative Metadata and Self-Describing Web to acknowledge the
reality of sniffing, due 2009-10-20 -- due 2009-10-01 -- OPEN

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

[45] http://www.w3.org/2001/tag/group/track/actions/308

action-308 due 20 october

<trackbot> ACTION-308 Propose updates to Authoritative Metadata and
Self-Describing Web to acknowledge the reality of sniffing, due
2009-10-20 due date now 20 october

lm: i don't like this action. you should refuse to do it

danc: Out of order

action-313?

<trackbot> ACTION-313 -- John Kemp to talk to Balisage participants
about XML namespace work, discuss TAG interest in this area, and
summarize -- due 2009-10-02 -- OPEN

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

[46] http://www.w3.org/2001/tag/group/track/actions/313

action-313 due 20 october

<trackbot> ACTION-313 Talk to Balisage participants about XML
namespace work, discuss TAG interest in this area, and summarize due
date now 20 october

<DanC_> action-313 due 20 Oct

<trackbot> ACTION-313 Talk to Balisage participants about XML
namespace work, discuss TAG interest in this area, and summarize due
date now 20 Oct

action-281?

<trackbot> ACTION-281 -- Ashok Malhotra to keep an eye on progress
of link header draft, report to TAG, warn us of problems (ISSUE-62)
-- due 2009-10-30 -- OPEN

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

[47] http://www.w3.org/2001/tag/group/track/actions/281

ashok: ongoing

action-304?

<trackbot> ACTION-304 -- Larry Masinter to draft summary of the
larger issue -- due 2009-09-30 -- OPEN

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

[48] http://www.w3.org/2001/tag/group/track/actions/304

noah: This is worth pursuing; need to look at minutes to see what
it's about

johnk: This was about the references in the HTML spec. HT had one
action, LM suggested there was a larger issue around references

action-304 due in one week

<trackbot> ACTION-304 Draft summary of the larger issue due date now
in one week

johnk: What the web platform looks like.

lm: I remember - I was going to add it to the versioning document

<noahm> action-304?

<trackbot> ACTION-304 -- Larry Masinter to larger around Web
Platform Definition regarding references in HTML 5 document -- due
2009-09-30 -- OPEN

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

[49] http://www.w3.org/2001/tag/group/track/actions/304

<masinter> regarding the definition of the 'web platform' with
regard to specs defined in the HTML5 document

action-action-306?

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-09-30 -- OPEN

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

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

<masinter> the general idea is that the web platform consists of a
set of interfaces, HTML, DOM, URI, RDF, images, etc., and that an
overall spec defining the platform should then make reference to
versionless versions of specs and alternatives

close action-306

<trackbot> ACTION-306 Work with JK and AM to update Web APplication
architecture outline based on discussions at TAG meetings closed

reopen action-306

<trackbot> ACTION-306 Work with JK and AM to update Web APplication
architecture outline based on discussions at TAG meetings re-opened

ashok: Let's meet at the end of next month

<DanC_> action-306: this is a follow-on action

<trackbot> ACTION-306 Work with JK and AM to update Web APplication
architecture outline based on discussions at TAG meetings notes
added

<DanC_> action-306?

noah: Please annotate the action in tracker?

<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-09-30 -- OPEN

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

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

action-311?

<trackbot> ACTION-311 -- Noah Mendelsohn to schedule discussion of a
persistent domain name policy promotion -- due 2009-10-01 -- OPEN

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

[52] http://www.w3.org/2001/tag/group/track/actions/311

ht: This was to follow up on Tim's plea to do something about
persistence of w3.org or persistent domains generally

[well that's not exactly what henry said.]

<DanC_> action-311: tbl notes
[53]http://www.w3.org/DesignIssues/PersistentDomains

[53] http://www.w3.org/DesignIssues/PersistentDomains

<trackbot> ACTION-311 Schedule discussion of a persistent domain
name policy promotion notes added

action-285 due in 2 weeks

<trackbot> ACTION-285 Make sure TPAC logistics are straight due date
now in 2 weeks

<DanC_> action-285?

<trackbot> ACTION-285 -- Noah Mendelsohn to make sure TPAC logistics
are straight -- due 2009-09-25 -- OPEN

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

[54] http://www.w3.org/2001/tag/group/track/actions/285

action-292?

<trackbot> ACTION-292 -- Noah Mendelsohn to alert group to review
HTML Authoring Drafts [trivial] [self-assigned] -- due 2009-10-13 --
OPEN

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

[55] http://www.w3.org/2001/tag/group/track/actions/292

noah will schedule discussion on this

action-284?

<trackbot> ACTION-284 -- Jonathan Rees to flesh out the Web
Application ( [56]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
) outline with as many sentences as he can -- due 2009-09-15 -- OPEN

[56] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

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

[57] http://www.w3.org/2001/tag/group/track/actions/284

<DanC_> ACTION-292: LMM notes Mike Smith's HTML spec is relevant

<trackbot> ACTION-292 Alert group to review HTML Authoring Drafts
[trivial] [self-assigned] notes added

close action-284

<trackbot> ACTION-284 Flesh out the Web Application (
[58]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html ) outline
with as many sentences as he can closed

[58] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

awwsw is talking about tag dec f2f as a 'delivery date'

action-312 due 1 december

<trackbot> ACTION-312 Find a path thru the specs that I think
contradicts Dan's reading of webarch due date now 1 december

action-312 due in one week

<trackbot> ACTION-312 Find a path thru the specs that I think
contradicts Dan's reading of webarch due date now in one week

action-201 due on 1 december

<trackbot> ACTION-201 Report on status of AWWSW discussions due date
now on 1 december

action-278 due 15 october

<trackbot> ACTION-278 Draft changes to 2.7 of Metadata in URIs to
cover the "Google Calendar" case due date now 15 october

<DanC_> action-282: jar says this is his project for the fall

<trackbot> ACTION-282 Draft a finding on metadata architecture.
notes added

action-33 due 15 october

<trackbot> ACTION-33 revise naming challenges story in response to
Dec 2008 F2F discussion due date now 15 october

<DanC_> (larry, is there a draft of HTTPbis which has advice on
conneg?)

action-232 due in 4 days

<trackbot> ACTION-232 Follow-up to Hausenblas once there's a draft
of HTTPbis which has advice on conneg due date now in 4 days

<masinter> (DanC, my proposed revision hasn't been incorporated yet)

<DanC_> (tx)

action-232 due on 29 september

<trackbot> ACTION-232 Follow-up to Hausenblas once there's a draft
of HTTPbis which has advice on conneg due date now on 29 september

<masinter> danc
[59]http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0792
.html

[59]
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0792.html

action-163 due 31 october

<trackbot> ACTION-163 Coordinate with Ted to build a sample catalog
due date now 31 october

discussion of action-295

noah: Back to the spreadsheet

[60]http://www.w3.org/2001/tag/2009/09/HTMLIssues.xls

[60] http://www.w3.org/2001/tag/2009/09/HTMLIssues.xls

HTML issue: text/html mime type

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

[61] http://tools.ietf.org/html/rfc2854

lm: RFC2854 is current definition of text/html. written by lm and
danc
... history ... mime types are allocated by IETF. Registration at
top level requires IETF consensus
... you designate a change controller. for text/html, it's W3C
... I assume that means rec, not a WG last call

<DanC_> [62]http://www.ietf.org/rfc/rfc2854.txt The 'text/html'
Media Type

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

lm: The proposal in HTML5 is to replace registration with something
*not* including any history [background]
... anything you 'should' need to know is contained in the rec,
anything else is a bug

noah: What is typical?

danc: There be dragons

lm: It's typical to include history, making updates less of an issue
... One reason given is to revoke the permission to serve
XML-expressed HTML as text/html

noah: Breaks our agendas and minutes?

danc: Probably not, since they match the syntax and semantics of
HTML5

timbl: The notion that there is an XML language that is an HTML
language is important as a matter of principle
... and that you can serve it as text/html

noah: The new spec correctly interprets [XHTML] content

lm: (no...)

noah: You shouldn't take stuff that's widely deployed and break it

danc: Depends on what you consider 'widely deployed'

lm: Purpose of mime type is give an out of band description of what
the sender intended
... It's not normative, it indicates intent

noah: Self-describing web has a story about answering the question
"did so and so serve a document x that can be interpreted according
to such and such interpretation rules" (jar's paraphrase)

lm: E.g. the profile attribute of head isn't in html5.

Receiver has no clue what the sender might have meant by a profile
attribute.

If the mime type registration doesn't give history, receiver doesn't
have a chance.

danc: There is some former-features explanation

timbl: Safest thing to do might be to make a historical RFC...

(someone:) how would that help follow your nose?

ht: At the moment we have hearsay, can we have some references?
Nothing in the July draft that looks like a mime type
registration... up to date reference?

<DanC_>
[63]http://dev.w3.org/html5/spec/Overview.html#iana-considerations

[63] http://dev.w3.org/html5/spec/Overview.html#iana-considerations

<DanC_> 12.1 text/html

<ht> What's the issue number for discussion of this?

[scribe notes that this is not a dated file. may change]

timbl: Bold and emphasized text - that must be a funny story

ht: You're now no longer allowed to serve some xml with this label.
The question is whether reinterpreting as html changes the document
in any visible way

<masinter> there were 5 different specifications and languages and
mulitiple implementations that the previous RFC made reference to...
these languages were more or less coherent and correlated. Writing
the history of each element piece by piece is not the same

danc: table with tr right underneath it - tbody gets implicitly
added by html at parse time - so different dom

<DanC_> (hmm... looking for a historical explanation of
head/@profile, I don't see that, but I see "must not be used by
authors" with what to do instead; it says "unnecessary; omit it
altogether, and register the names.")

lm: there used to be many html versions... the fact that someone
might meant one of those is lost when you chop it up feature by
feature. you lose the sense that someone was using a particular
dialect (language version).
... The intent is to outlaw declarations that a document is HTML 4
(etc)
... Rewriting history is absurd. That's what I think the TAG
response should be

ht: Is there any precedent for this? Has something like this
happened before?

<ht> ACTION: Henry S. to draft for tag@... proposed TAG feedback
on the text/html media type registration in the 25 September draft
of HTML5 recorded in [64]http://www.w3.org/2009/09/25-tagmem-irc]

[64] http://www.w3.org/2009/09/25-tagmem-irc

<trackbot> Created ACTION-316 - S. to draft for tag@... proposed
TAG feedback on the text/html media type registration in the 25
September draft of HTML5 [on Henry S. Thompson - due 2009-10-02].

<masinter>
[65]http://lists.w3.org/Archives/Public/public-html/2009Aug/1184.htm
l

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

<masinter> ... The main thing that needs updating is the removal of
the permission for sending syntactic profiles of XML as text/html.
In addition, the encoding considerations, fragment identifier
definition, and the text about recognising HTML documents are
somewhat out of date and can be significantly improved by
referencing HTML5 now. RFC2854 is quite vague in a number of areas,
also, which can be cleaned up with an update.

Geolocation/Geopriv

Thomas Roessler is joining us.

<noahm> The chair thanks Thomas Roessler for joining us on short
notice.

lm: I'm interested in current status. I met with Eve in Stockhom,
area directors, what is the IETF and Cisco and CDT response?

tr: I'm not the team contact, this info may be outdated...
... Comment was sent by IETF chair
... "We are working on the comments, something will be given"
... AFAIK they just haven't answered yet

<DanC_>
[66]http://lists.w3.org/Archives/Public/public-geolocation/2009Aug/0
016.html "We're working on drafting formal responses to the Last
Call comments we

[66]
http://lists.w3.org/Archives/Public/public-geolocation/2009Aug/0016.html

<DanC_> have received.

<DanC_> Unfortunately due to vacations this has been taking a bit
longer than we

<DanC_> had expected, but we will have them ready soon."

<johnk> DanC: I agree with this: Most well-intentioned sites,

<johnk> and _all_ evil sites (the ones where privacy leakage is an
issue in the

<johnk> first place) would just ignore the user's requests

<johnk> (and evil sites can just put their own code in there to
ensure that the user's information _is_ leaked)

<DanC_> suggestion: we've looked at the technical issues and a
little bit of the policy issues, and come to the conclusion that
there are several coherent designs and none of them critically in
conflict with web architecture. Maybe let's action somebody to take
the remaining liaison/process issues to the IETF/W3C liaison forum
or something.

<DanC_> (re orthogonality... the device API WG seems likely to
persue that approach)

<johnk> such as [67]http://www.w3.org/2009/policy-ws/cfp.html ?

[67] http://www.w3.org/2009/policy-ws/cfp.html

<johnk>
[68]http://www.w3.org/2008/security-ws/report#PolicyDescription

[68] http://www.w3.org/2008/security-ws/report#PolicyDescription

Adjourned until next time.

Summary of Action Items

[NEW] ACTION: DanC to follow up on best plan for HTML / TPAC
recorded in [69]http://www.w3.org/2009/09/25-tagmem-irc]
[NEW] ACTION: Henry S. to draft for tag@... proposed TAG feedback
on the text/html media type registration in the 25 September draft
of HTML5 recorded in [70]http://www.w3.org/2009/09/25-tagmem-irc]
[NEW] ACTION: John to talk to Balisage participants about XML
namespace work, discuss TAG interest in this area, and summarize
recorded in [71]http://www.w3.org/2009/09/25-tagmem-irc]
[NEW] ACTION: noah Check with Amy on room availability and suggest
to Ian that he mention this meeting in TAG election call for
nominations [recorded in
[72]http://www.w3.org/2009/09/25-tagmem-irc]

[69] http://www.w3.org/2009/09/25-tagmem-irc
[70] http://www.w3.org/2009/09/25-tagmem-irc
[71] http://www.w3.org/2009/09/25-tagmem-irc
[72] http://www.w3.org/2009/09/25-tagmem-irc

[End of minutes]
_________________________________________________________

Minutes formatted by David Booth's [73]scribe.perl version 1.133
([74]CVS log)
$Date: 2009/10/13 21:41:59 $

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

Text-only version of TAG F2F minutes of 25 June 2009

2009-08-10T13:46:51Z

A text-only copy of the minutes from the third day of the TAG's F2F
meeting in June, 2009 is attached.

Noah

[1] http://www.w3.org/2001/tag/2009/06/25-minutes.html

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

[1]W3C

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

- DRAFT -

TAG f2f

25 Jun 2009

[2]Agenda

[2] http://www.w3.org/2001/tag/2009/06/23-agenda

See also: [3]IRC log

[3] http://www.w3.org/2009/06/25-tagmem-irc

Attendees

Present
Raman, Noah, Larry, Dan, Henry, Ashok, Jonathan, TimBL, John

Regrets
Chair
Noah

Scribe
Ashok

Contents

* [4]Topics
1. [5]Naming Schemes
2. [6]HTTP Semantics
3. [7]TAG f2f scheduling
4. [8]Tag priorities and future work
5. [9]Architecture for Web Applications
6. [10]HTML 5 review
* [11]Summary of Action Items
_________________________________________________________

Naming Schemes

<scribe> scribenick: Ashok

<scribe> scribe: Ashok

HT: Introduces document [12]Dirk and Nadia design a naming scheme -
or - Web naming schemes good practices
([13]http://www.ltg.ed.ac.uk/~ht/justSayHTTP.html)
... I started over with Jonathan's help
... major strategic question: I could not find the right tone and
right audience
... I started writing this as a request from a W3C AC rep who wanted
a doc she could point to saying why we did not like XRIs
... There is a finding and a Journal paper mixed up in this document
... I now think I should stay with tone and audience of AWWW. Tone
is light, recapping known facts with examples
... it's a doc for people who are thinking about designing names on
the web. There may be a big appendix or a companion white paper

[12] http://www.ltg.ed.ac.uk/~ht/justSayHTTP.html
[13] http://www.ltg.ed.ac.uk/~ht/justSayHTTP.html

Noah: Pehaps a few minutes to read the paper first

LM: I have trouble with premise of the document
... people want to define new naming schemes, let them! What harm
are we preventing?
... I don't see anything that says "Wow, that's terrible!"

TimBL: The damage is fragmentation ... 2 webs. Each with it's own
naming scheme

Dan: There is a reputation that HTTP URIs don't really work. So, we
say HTTP URIs solve these problems as well as anything else.

LM: If you were to change the title doc "How to use HTTP URis to
identity long-lived resources robustly" that would capture your
intention

<Zakim> noah, you wanted to talk about fragmentation

Noah: We should talk about potential damage from other naming
schemes. Fragmentation
... If there is another scheme, software may change to handle both
schemes. Or it may not.

<masinter> google is the naming scheme: put the name you're looking
for into google

Noah: example of XRIs

LM: I gave a presentation in '99 -- problems URis don't solve
... some problems are not solvable

<masinter> [14]http://larry.masinter.net/9909-twist.pdf

[14] http://larry.masinter.net/9909-twist.pdf

<Zakim> noah, you wanted to suggest we read the draft

HT: Some problems are about social contracts and no scheme can solve
them
... Section 2 is almost unchanged

<noah> project which involves --> project that involves ??

<noah> Kill the paragraph beginning: Following the precedent of
AWWW, we proceed ... ??

<DanC_lap> ed: the use of 'AWWW' grates on me

<DanC_lap> "At this point Dirk and Nadia both reply at once" was
going to have a 3rd option, to use http, when last we discussed
this, IIRC.

<DanC_lap> rather than "on the wrong track"

<timbl> "and the contingent nature of name registration" is fancy
language for a non-academic document.

<noah> they all want names which are identifiable ===> what does it
mean for a name to be identifiable?

<noah> ah, explained later.

<noah> I still don't like "URI in the scheme", because I think it
uses the word scheme in a somewhat broader sense than RFC 3986

<DanC_lap> (does transparent subsume identifiable? maybe not as
requirements)

<noah> transparent: as an aside, I wonder if a reference to the URI
templates work would be helpful in this context

<timbl> "The IETF has rebound the http: scheme at least twice since
its original binding." Well, hst, in a away, but in a way not: it is
permanently bound t the evolving HTTP protocol, just as you have
argued that [15]http://www.w3.org/ is correctly bound to an evolving
home page.

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

<timbl> There is no reason why we could not make a design in which
domain names are permanent. I have proposed this
[16]http://www.w3.org/DesignIssues/PersistentDomains.html

[16] http://www.w3.org/DesignIssues/PersistentDomains.html

<timbl> The TAG could instigate it

<noah> not quite sure the term "self-describing" is used in the same
sense as in the SDW TAG finding. If different, then that's
confusing.

<DanC_lap> "So, let's try a rewrite" is that an ed-note of sorts? I
don't think I grok.

<noah> SDW Web finding really focuses on the chain of
specifications, not retrievable metadata

<masinter> there are 40 URN namespaces registered, of which most are
not in common use. I'm not sure why the TAG is spending time on
something that isn't really a serious threat to web stability

<masinter> compared to many other more serious threats... i don't
see the "split" really happening. People use HTTP schemes reguarly
for identifying everything.

<masinter> an examination of other URI schemes and how they are or
aren't used for identification might be interesting, as is an
examination of the requirements

<masinter> when are GUID-based URI schemes appropriate?

<DanC_lap> "4.1. http: URIs are identifiable" could use an example

<masinter> what about protocol-specific schemes such as "mailto:" vs
"smtp:"

<noah> Typo: The each identify a resource

<masinter> What about message-IDs in email messages and their
mapping into HTTP space?

<masinter> What about form parameters in HTTP URIs and the problems
with charset encodings?

<masinter> What about "file:" and its difficulties in mapping in an
operating system independent way and the lack of a credible
"authority" in most "file:" URIs?

<masinter> what about "widget:" vs "thismessage" for the Widget
identifier?

<noah> http: -> "the http URI scheme (which we will hereafter
abbreviate as http:). I've tripped several times over the fact that,
per 3986 grammar, the colon is not part of the scheme name

<DanC_lap> Larry, how many people _know_ that there are 40 URN
namespaces registered, most of which are not in common use? Are you
sure it's not worth telling a few more people what you/we know?

<masinter> Well, how does this draft and approach do that?

<masinter> i'm not questioning that the TAG could do some useful
work in the URI space, i'm just questioning this approach at the
problem, considering my own experience in naming resources in XMP
and the dfficulties I had

<DanC_lap> I'm not sure this draft does; we've tried several other
approaches. There's no magic.

<timbl> I would like Dirk and Nadia to end up with a conversation in
which the fragmentation issue is debated against their excitement
about being about to work for a few year son engineering their own
solution.

<masinter> I have a confession about having invented URI schemes for
Dirk and Nadia

HT: In terms of addressing the underlying issue which is providing a
resource for people thinking about what to do in this space, I think
the most valuable aspect of this doc is the taxonomy in section 3

<DanC_lap> I think the XMP URIs didn't have the
usability/dereferenceability requirement, did they, masinter ?

HT: if you look at the literature on persistence you find a range of
wolly thinking. Getting clarity on what people want from names is
hugely valuable.
... any gap in this terminology is very important to me
... this is not a knock-down-drag-out use HTTP. It tells the
strengths of HTTP but does not analyze other schemes
... need to say that HTTP URIs work

Dan: They often say they don't have that requirement
... I added security at the end and I have a question on that

LM: I just invented 2 URIs schemes
... and I got my company to implement them
... so I'm feeling a bit attacked by this document
... anonymity was a requirement. Identity of art house that did
post-producition markup should not be deriveable from the URI
... every video we identify has some metadata

<masinter>
[17]http://www.adobe.com/devnet/xmp/pdfs/DynamicMediaXMPPartnerGuide
.pdf#page=19

[17]
http://www.adobe.com/devnet/xmp/pdfs/DynamicMediaXMPPartnerGuide.pdf#page=19

<ht> So, 'global' is an implicit requirement which I should make
explicit

Dan: The samentics of GUID ... [missed]

LM: There is unique place to put metadata. 2 identifiers: which doc
and which instance
... there is a history chain

Dan: You have some way of looking this up?

HT: It's a cool scheme but does not share 2 or more requirements
that are listed

Noah: You did not mention ability to email identifiers
... is that a requirement?

TBL: Isn't NM's example covered by 'useable'

<ht> I am in two minds about whether 'global' is usefully
distinguishable from 'useable'

LM: The presumption is that stuff moves. And I want to retain
identity
... There is an index
... Dirk and Nadia will not be happy if they have a URI and things
have moved. Unreliable when things move. Better is use of index --
that requires more work

HT: Distinguish what the technology does and what the social
contract does
... If you move then you have to implement a redirect

LM: Requirement to identify things in situations where things move
and no opportunity to set up redirects and yet want to associate
metadata after the fact
... retains identity after move.

Tim: 2 types to identifiers GUID identifier which has this property
and another style which does not

<jar> maybe 'branded' instead of 'identifiable'

<jar> (branded to the naming scheme, not to the movie house)

HT: I have not been careful about that ...

Tim: This is very different from a GUID scheme.

LM: this is putting metadata in the identifier.

TimBL: People want that

<jar> analog with new uri scheme would be the uri scheme itself, not
its user

LM: You want identity to be longer lived than the brand
... Some of these requirements are orthogonal to HTTP

HT: Yes... if you recognize these requirement then HTTP satisfies
them. You may have other requirements

Tim: If we say these are just names but people have other needs

HT: Value of this doc is to identify requirements carefully. So
people can say whether they apply to them or not
... someone has a requirement that names not be transparent

Noah: I tell people in IBM that people have requierments like these
that they did not recognize
... we need to discuss pros/cons of implementations as well as
requirements

<masinter> I think the document as written seems to talk about
things as "requirements" when there are tradeoffs and there are
properties of different URI schemes and situations

<masinter> anonymity vs. identifiability

<masinter> anonimity

Noah: we would do well to say the goal is to present a balanced view
of the tradeoffs

<masinter> resolvability vs. permanence in the face of things moving
outside of your control

<Zakim> ht, you wanted to answer larry: identifiable; global

<Zakim> jar, you wanted to ask lm so how did adobe think the
requirements were going to be met? and to wonder whether the
requirements can be partitioned into two sets: the ones that enable
the argument, and other ones that can *also* be met (deconstruct
'whose requirements for what')

JR: Would be excellent if we could get the requirements in good
shape

<masinter> I'm willing to serve as the prototypical "Dirk"

JR: please examine requirements carefully and say what applies and
what does not

<masinter> I take responsibility for the "requirements", don't blame
adobe

<masinter> i'd rather see "How to use HTTP URIs and still meet some
requirements that you didn't think you could meet with HTTP URIs"

JR: Requirements serve 2 purposes: make people aware of what
requirements are and to weed [?] people and then say these are what
HTTP provides

<Zakim> DanC_lap, you wanted to contrast the guuid pattern with the
pattern of an administrative hierarchy

JR: perhaps sort requirements into 2 groups

<masinter> administrative and organizational heirarchy *must* be
opaque

Dan: Pattern or admin hierarchy gets lost ... different from GUID

<jar> 2 kinds of requirements. 1. let people figure out whether the
advice is going to apply to them (whether they can ignore it), 2.
additional requirements that *can* be met in systems of the sort
that are recommended.

<masinter> strong customer requirement for not making internal
organization or work processes visible or stripping such information
while not losing identity

LM: uncomfortable calling desired properties as requirements

JR and Dan agree on 2 piles of requirements

HT: This is about Dirk and Nadia's requirements

LM: I know people in similar situations who have different
requirements

Tim: Can you supply alternative text?

LM: If it's a requirement it's a MUST. If it's a should it is not a
requirement

Noah: Applications may have different requirements

<ht> I'm happy to talk about goals/desiderata/etc., but I'm familiar
with the notion of "requirements capture" which doesn't imply MUST

<masinter> Well, i've gotten some feedback to that effect, and I
have some sympathy with Henry's terminology, i'm not sure about
whether everyone in Dirk and Nadia's situation have those same
requirements

<Zakim> ht, you wanted to ask about 'global' vs. 'useable'

<masinter> because the 'requirements' may be in conflict

HT: I would like comments on ....
... I don't use the word persistence becuase use it in different
ways

<masinter> if people use the word 'persistence' incorrectly, then
the finding should say why the meaning is imprecise

HT: wanting resource stability 'Cool URIs don't change'
... that's what people also want from 'persistence'. Sometimes they
want something stronger which I call representation stability ... I
want the same bits

<masinter> the main thing people are confused about is the
difference between 'having a name' and 'having a guarantee of a
future service of name lookup', and people being tied to name
resolution services without being aware of it

HT: people say they want this but they often do not

HT ... time varying resources

<masinter> documentid and instanceid separate intent vs.
representation

<masinter> think identity should be 'weak etag' or 'etag' identity

JR: It was an explicit requirement for LSID that if you get the data
you get exactly the same data ... this is to support replicability
of experiments

HT: This is a real representation stability requirement
... example is public key ... need same bits

<masinter> think this is missing the economics aspect

<jar> maybe 'purpose stability'

<masinter> noah talking about 'data:' URI scheme

Noah: Suggesting that a case to think about pros and cons of a
scheme called data vs. http

HT: What I intend to do is finish the rewrite so that if people stop
after section 4 they will have got the jist of the argument
... would like to enlist Jonathan's help again
... on requirements capture
... by the end of July I will be able to provide a completed draft
thru section 4

Noah: Are ready to agree to this?

LM: I'm uncomfotable with direction of this. So I'm reluctant to
agree

HT: That's fair warning

Noah: Larry, are you saying that I wish this went away or are you
saying this area of clarification is useful but don't like
direction.

LM: I'll talk to Henry on the break

BREAK for 15 minutes

HTTP Semantics

JR: Presents

<jar>
[18]http://lists.w3.org/Archives/Public/public-awwsw/2009Jun/0064.ht
ml

[18]
http://lists.w3.org/Archives/Public/public-awwsw/2009Jun/0064.html

JR: weekly telcons for ad hoc task force
... putting relationship between HTTP and RDF on a more rigorous
footing
... Explains linked-data nose-following from RDF or RDF terms to
more RDF

<masinter> thinks we need something that abstracts away from "HTTP
as spoken" and proposes an abstraction which can be mapped to HTTP
for better orthogonality

Tim: Asks about David Booth's rules

<jar> [19]http://esw.w3.org/topic/AwwswDboothsRules

[19] http://esw.w3.org/topic/AwwswDboothsRules

JR: These are nose-following rules
... I want to compare these to my version
... mine are written in bash [not N3]

<masinter> architectural principle of orthogonality: HTML shouldn't
depend on or rely on HTTP. I think same is true for Semantic web.
Definition of semantics and meaning shouldn't be tied to "http:".
However, would like some abstraction. "GET with success" vs. "GET
with redirection" is fine. Both "http" and "ftp" implement "GET with
success", but in HTTP it is a 200 response

<masinter> "ftp" doesn't implement "redirect", but HTTP does, and
uses 301 code

<masinter> inserting a level of abstraction helps identify what part
of HTTP is being used

JR: for all redirects resource resides at different URI

<masinter> What does semantic web *need*? Rather than trying to
describe HTTP, describe what Semweb needs and how HTTP can deliver
it

HT: Asks about 307

Tim: This is not true of 302

JR: It's saying what you believe is true
... e.g. the correspondence held at these times

JR: I have sent in some gentle suggestions
... Explains [20]diagram
... boxes are types [classes]. Solid headed arrows say the
relationship holds between some instances of the 2 types.

[20] http://www.w3.org/2001/tag/awwsw/jar-diagram-7.pdf

LM: I have some general comments

Yellow boxes are classes and relationships used in the curation

scribe: white boxes ... discussion

<raman> calling zakim

JR: I would call them 2616 resources. 'Resource' as defined in 2616

<raman> ethere by myself now a single unbalanced tag ...

LM: Need abstraction layer ...

JR: That's what this is.

LM: Is this descriptive or prescriptive?

<raman> I'll wait another minute then give up, hang up

Raman, we are dialing in

LM: Problem is some edges are not captured.

JR: I'm capturing edges used in linked-data
... I can put something in front explaining the space

LM: Idealized abstraction of HTTP useful for ... disclaimer of this
sort

Dan: I'm not seeing this that way. He's giving labels to concepts in
the spec

<masinter> use case: content-type sniffing

JR: constraints within which a resource operates

LM: Content negotiation

JR: and time-varying resources

LM: Content sniffing

<Zakim> masinter, you wanted to wonder if the intent is to be
descriptive or prospective

LM: Sniffing is there for a reason... they did not want to do it but
found they must
... if we could capture the reason that would be useful
... TAG has been accused of letting theory get in the way of
practice

Tim: We can model a clean or dirty system
... we can model the game theoretical basis basis
... you have to do the game theory of both parties .... browser
manufacturers

LM: We should at least identify agents to figure out who is being
gamed by whom

JR: My approach is to create subclasses
... then [ideally] we can prove some theorems about the consequences
of that

LM: Another layer between msg and media
... , would give you a place to see where content sniffing goes on
and who is doing it
... if model is helpful in thinking about this then that validates
it
... Char-set defaults which is a kind of content sniffing and
mapping this to less functional protocols

JR: Metadata could give you the correspondences

LM: Should tie abstract TAG work to what people are concerned with

Noah: That will keep this work pertinent
... but people have issues that this will help with
... about content neg there is squishiness about what a resource
really is

JR: We could talk about generic resources or httpRange-14
... I did a review of issue-57. I think it would be good to drive
this to closure

LM: How would Raman's doc fit into this model?
... Can this model help use describe where Web Arch is going, where
the ambiguities are ...

<masinter> can it help us understand web applications?

<masinter> when the message contains 5 lines of HTML: 4 imports of
javascript and one 'all' that then draws things on the screen

HT: A large gap between the representation and the resource ....
Javascript stretches intution about resources

Raman: Agrees ... we are at the point where we need one more concept

HT: presentation

Raman: Generator
... content is generated

LM: I have been using 'behaviour'

Tim: I like patterns
... discusses different patterns .... some simple, some very complex
... patterns used to a greater or lesser extent

Noah: I hope we can tell that same story informed by this analysis
to fill in table of contents

HT: Picture can be used with different patterns

JR: Wrapping up ... glad to hear this ... this is very abstract
... what Tim calls patterns, Alan calls classes
... would be good to explain this

Noah: Where are we going with this ?
... next session is about TAG priorities

LM: Getting examples of how this will describes controversies and
problems would be very good.

BREAK UNTIL 1:30 PM

TAG f2f scheduling

<DanC_lap> scribeNick: DanC_lap

PROPOSED: to meet 8-10 Dec 2009 in Cambridge, contingent on
consulting with John and Raman

<noah> Note that we agreed that chair will check with Raman and John
on this.

<noah> ACTION: Noah to check with John and Raman on agreed Dec. 8-10
2009 MIT F2F [recorded in
[21]http://www.w3.org/2009/06/25-tagmem-irc]

[21] http://www.w3.org/2009/06/25-tagmem-irc

<trackbot> Created ACTION-286 - Check with John and Raman on agreed
Dec. 8-10 2009 MIT F2F [on Noah Mendelsohn - due 2009-07-02].

RESOLUTION: to meet 8-10 Dec 2009 in Cambridge, contingent on
consulting with John and Raman

<raman> calling zakim

<noah> Strong preferences for avoiding following week

TVR: not sure I can make the 8-10 Dec meeting in Cambridge, but no
objection to it

<scribe> scribenick: DanC_lap

Tag priorities and future work

<ht> tv, we are resuming -- you there?

Note NM takes notes offline... (Checked in at
[22]http://www.w3.org/2001/tag/2009/06/TagPriorities.txt)

[22] http://www.w3.org/2001/tag/2009/06/TagPriorities.txt

NM's notes say, roughly: 1) HTML 5 2) Web Applications Architecture
3) Other things to do with metadata

NM: so where does URNsAndRegistries-50 fit?

[missed answer]

AM: and geolocation? where does that fit? webapps?

LM: yes, I think so, at a high level

NM: OK, so revise this to be our Primary Focus split -- there's room
for wind-down of existing work, and high-priority interrupts as
necessary

<jar> Where it fits: urnsandregistries is a 'secondary' focus

NM: I think we have actions on metadata, right?

[right]

action-283?

<trackbot> ACTION-283 -- Larry Masinter to update document on
version identifiers w.r.t. Cambridge June discussion -- due
2009-07-24 -- OPEN

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

[23] http://www.w3.org/2001/tag/group/track/actions/283

close ACTION-270

<trackbot> ACTION-270 Provide additional material for review at F2F
for Issue 41 closed

close action-272

<trackbot> ACTION-272 Report back to the TAG on outcome of
collaboration with LM on Versioning closed

action-282?

<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
metadata architecture. -- due 2009-08-31 -- OPEN

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

[24] http://www.w3.org/2001/tag/group/track/actions/282

<noah> [25]http://www.w3.org/2001/tag/2009/06/TagPriorities.txt

[25] http://www.w3.org/2001/tag/2009/06/TagPriorities.txt

<noah> [26]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

[26] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

action-283?

<trackbot> ACTION-283 -- Larry Masinter to update document on
version identifiers w.r.t. Cambridge June discussion -- due
2009-07-24 -- OPEN

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

[27] http://www.w3.org/2001/tag/group/track/actions/283

<noah> [28]http://www.w3.org/2001/tag/2009/06/TagPriorities.txt

[28] http://www.w3.org/2001/tag/2009/06/TagPriorities.txt

action-278?

<trackbot> ACTION-278 -- Jonathan Rees to draft changes to 2.7 of
Metadata in URIs to cover the "Google Calendar" case -- due
2009-07-07 -- OPEN

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

[29] http://www.w3.org/2001/tag/group/track/actions/278

NM: this looks good... the actions we assigned over the last few
days align well with these priorities

<noah> [30]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
.
.
.

[30] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

Architecture for Web Applications

NM: so we have
[31]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html ... Jonathan
has the action to carry it forward...

[31] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

action-284?

<trackbot> ACTION-284 -- Jonathan Rees to flesh out the Web
Application ([32]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html)
outline with as many sentences as he can -- due 2009-07-01 -- OPEN

[32] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html)

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

[33] http://www.w3.org/2001/tag/group/track/actions/284

jar, fyi, COMA?T is comet

jar: I started making larger clumps...

NM: this might be as much a taxonomy of issues more than a TOC

jar: yes... something about the TOC structure didn't suit me

<noah> [34]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

[34] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

DanC: how about trying a pattern language wiki?

HT: what's that?

<timbl> Maybe [35]http://c2.com/cgi/wiki

[35] http://c2.com/cgi/wiki

<DanC_> yes, esp [36]http://c2.com/cgi/wiki?PatternLanguage

[36] http://c2.com/cgi/wiki?PatternLanguage

<timbl> [37]http://perldesignpatterns.com/?PerlDesignPatterns

[37] http://perldesignpatterns.com/?PerlDesignPatterns

TimBL: Christopher Alexander wrote a book on architecture
patterns...

NM: and there's a software Design Patterns book

DanC: yes, something like that... a collection of problem/solution
patterns

JAR: I'm happy with the OWL WG wiki

[discussion of mechanics]

[discussion of policies]

<jar> actually that's *very* happy. they did a great job. lots of
cool add-on technology e.g. they generate WDs directly from the
wiki.

TBL: I'm interested in a pattern wiki for its own sake... remember
that for things like web applications we're not the experts

JAR: I think a TAG wiki is likely useful for patterns and other
things... use cases... anything we can get the community to
contribute helps us multiply our few resources

AM: I'm a bit concerned that not everything fits so well into
patterns

<jar> owl wiki is only writable by WG members

boring

<jar> right. not recommending that.

<jar> there's access control

<jar> groups

<masinter> I think the role of the TAG is different from that of a
working group

<masinter> I don't think the TAG's role or responsibility is to
represent the "consensus" of the community, in the same way that a
W3C working group *does* have that responsibility

wow.

"W3C has created the TAG to document and build consensus around
principles of Web architecture" --
[38]http://www.w3.org/2004/10/27-tag-charter.html

[38] http://www.w3.org/2004/10/27-tag-charter.html

<masinter> yes, document and build, not represent

LMM: the TAG's responsibility to compromise to get consensus isn't
as great as a WG with an implementation community

<masinter> well, not exactly

<masinter> the TAG is responsible for leadership, which may not
require compromise

NM: supposing we thought it was a good idea, Dan, are you willing to
maintain it?

DanC: yes

timBL: couldn't we just use the esw wiki?
... Noah, do you ever use the esw wiki?

NM: NM: I use it and it has some serious shortcomings. It's slow and
it uses a non-standard markup language, which is a big nuisance when
you are trying to copy/paste HTML or other standard formats.

<masinter> I don't think anyone has the 'responsibility' to
'compromise'... Working groups have a responsibility to reach
consensus, and that may require compromise. The TAG has a
responsibility for leadership, and compromise is not as useful a
tactic for leadership

<masinter> leadership means getting people to follow. it means
making proposals that make sense to the community, and dealing with
input. this is getting pretty far off the topic of wiki though

NM: hmm... discussion of the wiki doesn't seem to come to any
particular conclusion
.
.

NM: so on architecture for web applications... are we agreed that
explaining the community how to use web architecture to build web
applications as well as publish documents is a priority?

LMM: well, the community knows how to build them...
... we're trying to develop architectural guidelines
.
.

<masinter> we're going to develop what we believe are useful
architectural guidelines

HTML 5 review

[discussion of how to organize review of HTML 5 ]

LMM: I'm willing to do a guided tour of a couple specific sections

poll shows 3~4 think assigning sections to TAG members is a good
idea. [missed other numbers; help?]

LMM: let's look at sections together
... In particular, I'd like to follow up on criticisms that it's too
long, algorithmic, browser-specifc, [and a few others]

<jar>
[39]http://random.org/integers/?num=80&min=1&max=1099&col=8&base=10&
format=html&rnd=new

[39]
http://random.org/integers/?num=80&min=1&max=1099&col=8&base=10&format=html&rnd=new

<noah> ACTION: Noah to schedule telcon time for Larry to walk us
through a few short sections of HTML 5 document [recorded in
[40]http://www.w3.org/2009/06/25-tagmem-irc]

[40] http://www.w3.org/2009/06/25-tagmem-irc

<trackbot> Created ACTION-287 - Schedule telcon time for Larry to
walk us through a few short sections of HTML 5 document [on Noah
Mendelsohn - due 2009-07-02].

<DanC> I bid for sections 1 and 2

AM showed interest in offline apps

NM: we could [...] or let people express interest in email

<masinter> (/ 1000 9) = 111 pages each

<masinter>
[41]http://www.whatwg.org/specs/web-apps/current-work/html5-letter.p
df

[41]
http://www.whatwg.org/specs/web-apps/current-work/html5-letter.pdf

<noah> ACTION: Henry to arrange "divying" of HTML 5 into sections
such that each part of spec is read by at least one TAG member
recorded in [42]http://www.w3.org/2009/06/25-tagmem-irc]

[42] http://www.w3.org/2009/06/25-tagmem-irc

<trackbot> Created ACTION-288 - Arrange "divying" of HTML 5 into
sections such that each part of spec is read by at least one TAG
member [on Henry S. Thompson - due 2009-07-02].

<timbl> Presumably not [43]http://www.w3.org/TR/html5/

[43] http://www.w3.org/TR/html5/

<DanC> why not, timbl?

<masinter> that document has 979 pages

<timbl> Beause it is not as freshas
[44]http://dev.w3.org/html5/spec/Overview.html

[44] http://dev.w3.org/html5/spec/Overview.html

<DanC> I think reviewing /TR/html5/ is good in that it motivates the
HTML WG to publish more often

<timbl> It means our reviews would be less relevant

<DanC> doubt it

<DanC> maybe in some cases

<masinter> ask you that when you're reading to see if there's some
way of articulating issues that are general but backed up by
specifics

<timbl> I have Version 2.2.1 (4132) and it seems to work

ADJOURN.

Summary of Action Items

[NEW] ACTION: Henry to arrange "divying" of HTML 5 into sections
such that each part of spec is read by at least one TAG member
recorded in [45]http://www.w3.org/2009/06/25-tagmem-irc]
[NEW] ACTION: Noah to check with John and Raman on agreed Dec. 8-10
2009 MIT F2F [recorded in
[46]http://www.w3.org/2009/06/25-tagmem-irc]
[NEW] ACTION: Noah to schedule telcon time for Larry to walk us
through a few short sections of HTML 5 document [recorded in
[47]http://www.w3.org/2009/06/25-tagmem-irc]

[45] http://www.w3.org/2009/06/25-tagmem-irc
[46] http://www.w3.org/2009/06/25-tagmem-irc
[47] http://www.w3.org/2009/06/25-tagmem-irc

[End of minutes]
_________________________________________________________

Minutes formatted by David Booth's [48]scribe.perl version 1.134
([49]CVS log)
$Date: 2009/07/21 22:17:44 $

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

Text-only version of TAG F2F minutes of 24 June 2009

2009-08-10T13:46:07Z

A text-only copy of the minutes from the second day of the TAG's F2F
meeting in June, 2009 is attached.

Noah

[1] http://www.w3.org/2001/tag/2009/06/24-minutes.html

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

[1]W3C

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

- DRAFT -

W3C TAG Face To Face meeting

24 Jun 2009

See also: [2]IRC log

[2] http://www.w3.org/2009/06/24-tagmem-irc

Attendees

Present
jar, johnk, timbl, jk, noah, masinter, ht, dc

Regrets

Chair
noah

Scribe
timbl, masinter, Ashok

Contents

* [3]Topics
1. [4]Mobile Web
2. [5]Metadata Access and Formats
3. [6]Versioning and HTML
4. [7]Web Arch for Applications
5. [8]tag administration issues
* [9]Summary of Action Items
_________________________________________________________

Mobile Web

<masinter> Date: 24 June 2009

<masinter> ScribeNick: timbl

(discussion of deployment of smart phones, vs SMS capabilities)

Noah: Do people just expect them to get IP and use the web, or will
they stay with SMS?

jk: Well, phones last, with repeair services, for a long time in
developing countries.

HT: Even my phone does some web, and its level is well deployed in
developing countries.

NM: I would have thought that a little bit of graphics would make it
much easier to make an intuitive, say, banking application, compared
to just using SMS (which of course they do.)

Tim: The SMS limitation of 140 character seems to have taken off
with microblogging

Noah: The person who built twitter was before that fascinated by the
communication (by SMS) between bicycle delivery people in New York.

jk: XMPP is very interesting in the mobile space.
... Hybrid bi-directional protocols become more friendly than old
HTTP.
... These things are being integrated in HTML5, and things like
Comet which allow long-lived connections between things like a
mobile phone and effecive a pub/sub service.
... Again, not clear how many of these issues are actually limited
to the mobile world.

Larry: It is mobile-related in the sense that the mass of deployment
is changing dramatically, so there are many more mobile phones than
PCs.
... As the performance increases, that dominance will rise
enourmously.
... Most people on the web will be mobile users talking to the coud
not PC users.
... We should not then only focus on the desktop/laptop architecture
or we will miss this.
... I think mobile is a lot of what is fuelling HTML5 and WebApps
development.

jk: Comet is HTTP long-polling .... connecting up to a server so
that effectively small messages can be sent from server to client.

<DanC_lap> (is anybody on the TAG watching the new list on comet
etc.? hybi is it?)

<johnk_> [10]http://en.wikipedia.org/wiki/Comet_%28programming%29

[10] http://en.wikipedia.org/wiki/Comet_%28programming%29

<johnk_> [11]https://www.ietf.org/mailman/listinfo/hybi

[11] https://www.ietf.org/mailman/listinfo/hybi

NM: For a bank, for example, most of the time I get a web site for
laptop use, but a native app for an iPhone. So we have this move for
lots and lots of applications.

Larry: If I am Fidelity, have a big back-end, I want to make it
available from wherever people are. I want to adapt it at the last
moment to the user. If necessary, I will build a native app.

NM: But it is a pain to wrote a different app for each platform.
... The market seems to be suggesting that the web is not good
enough for these domains.
... That is why we really need good webapps, so that we build one
web and they build one web application.

(discussion of web applications that are just bookmarks)

Larry: I think the motivating force for web applications is
mobile... the goal is to blur the line between an app and a
bookmark.

Noah: On the iPhone, you can now use gmail when completely offline,.
All your gmail information is downloaded into local storage from the
web... but you can't get at the contact list because of the
sandboxing.

Jonathan: (Doesn't work for me.)

Noah: So the need now is for an API for getting at the local contact
list.

<DanC_lap> (hmm... iPhone as gaming platform is getting pretty
interesting. I wonder whether to bring that up here/now.)

<johnk_> [12]http://www.w3.org/2008/security-ws/report#Concrete -
device APIs currently in W3C charter

[12] http://www.w3.org/2008/security-ws/report#Concrete

jar: There is pressure to make separate phone apps for newspapers,
banks, etc, and I suspect it is because of deficiencies in APIs.
This will be fixed as it was for desktop applications ... It was
made it easier to install desktop apps. For browsers it will get
easier.
... Our job is to think: what might go wrong as that rolls out?
... If we see some danger in incompatability between, say access to
contact lists, we must work to prevent problems, where market
pressure does not help.

Ashok: I don't think it will take the same number of years .. it
will be faster.

<Zakim> johnk_, you wanted to mention what I see as the two possible
architectural issues

<Zakim> noah, you wanted to talk about security

jk: From everything I have written down, here are two arch issues:
Merging of pub/sub XMPP events into the protocol, and security and
privacy in a world where you have HTTP server running on your phone
... closely connected to an individual and serving private data.

NM: The people who develop mobile devices have been more paranoid
about keeping the platform secure than the browsers. Even the native
iPhone apps have lock-down sandbox model.

<johnk_> correcting the "you have something which is the equivalent
of an HTTP server running on your phone" to "you have something
which is the equivalent of an HTTP server running on your phone"

NM: This sandboxing gives a much stronger assurance that e.g. my
contact list won't get stolen or trashed. This will be an important
factor for the deployment of web apps.

Larry: The history of the mobile industry and its interaction with
the web has been rocky.
... WAP, CHTML, and attempts to build a separate infrastructure
instead of working with the existing standards groups ...

jk: (Sometimes mobile not well listened to)

Larry: There was not an effective way of working together; we should
make sure there is in future.
... With security and privacy, market forces are not as good drivers
as with features.
... With features, you can deploy 20 and the market will select the
ones you need.
... With security and privacy, the consequences of getting it wong
is very delayed. So the market does not select things properly. So
we the TAG should put more effort into those things.
... there has been a lot of handwringing but I think IETF has put a
lot of work in here.
... We should understand the history and background in this area
before we work in it.

<Zakim> DanC_lap, you wanted to note software installation is more
about "yes, you can run your code on my behalf" than downloading
bits... and wonder how much of the market the W3C

DanC: Talking about sandbox models. With client-side caching this is
more about users saying "yes you can get access to this"
... Keeping the bits is not what is important, but getting and
caching the permissions is important.
... Gears, or HTML5 data access are used.

Noah: You get a SQL-lite database on your phone just from visiting
the gmail site, without giving them permission to use space on the
machine.

<masinter> ((monetization policy is a motivation for separate apps,
as well as the top level 'app' bookmarks))

<noah> As I understand it, Google has written a GMail client that is
mostly portable from Android to iPhone (more to come), but is using
Gears on Android, and Safari HTML5 store on iPhone.

<DanC_lap> [13]http://www.w3.org/TR/2009/WD-widgets-20090528/

[13] http://www.w3.org/TR/2009/WD-widgets-20090528/

danc: On Android, there is a set of control bits for each
application. Note that the widget spec is related to this, just went
to Last Call.

TimBL: Isn't it a goal to make desktop and web app installation to
become equivalent and connect directly?

<Zakim> johnk_, you wanted to mention the HTML5 discussion

<DanC_lap> (I can't find the list of permissions in the widgets
spec; help?)

jk: There are two very important identities - the user and the
company which made the app.

timbl: Don't assume the company is active as the user's agent.

jk: Is HTML5 the format we will use for new user interfaces? Or will
there be completely different interfaces -- like voice interfaces --
which may need very different languages.

<Zakim> timbl, you wanted to discuss what parts there are of what we
think of as installation. Access to data, accecss to resources -
memory, disk, cpu, screen space, attention,

Noah: BREAK

Metadata Access and Formats

Noah: We have four issues around this
... 57,62, 63, 54 (See the Agenda)

Larry: I have been tardy in opening a new issue-63, I was thinking
about how to frame it.

Noah: Let us deal with all 4 issues in this session.

Ashok: I think we should separate the access and the format.
... On the access front, there is no new news, though Eran and Mark
Nottingham has promised us a new draft.

jar: LRDD

<noah> JR: Current drafts are linked from our agenda

<Ashok> New drafts expected from Eran Hammer-Lahav

<jar> Eran and Mark are preparing new drafts, but they're not ready
yet. So we can't talk about them yet.

<noah> Email from Jonathan (linked from agenda):
[14]http://lists.w3.org/Archives/Public/www-tag/2009Jun/0060.html

[14] http://lists.w3.org/Archives/Public/www-tag/2009Jun/0060.html

<noah> That email has links to drafts

Ashok: On the access part, we should just wait.

<noah> AM: On metadata access, I think we should wait

Ashok: For the format part, I leave it to Jonathan.

Larry: I have the idea that we might have an architecture for
metadata which might describe the relationship of semantics for URIs
and resources and semantic web assertions about resources, and the
ways in which specific protcols might contain features which might
advise you about other metadata, so that, for example, HTTP and HTML
are just instances of more general classes of things.

When I thought abou framing the metadata issue, it was to to try not
to tie the idea to HTTP specifically.

Larry: I think we can make progress on that idea independently of
the way of accessing metadata specifcially.

<Zakim> jar, you wanted to talk about relation to nose-following

jar: To address that, I agree with Larry, that quite a lot of this
is architectural rather than tied to some specific protocol.
... There is the "self-describing" or nose-following, web.
... that is very close to the Linked Data movement, which has
developed its own protocol for browsing the web for data about
anything, not just data about documents.
... One idea which runs through this is .. are we talking about
third party metadata, or just about second party metadata?
... The first party might be browser, the second party the
publisher, third party the reviewer?
... We should say that one can get data from many different sources.
Ther are trust, authority issues.
... This is not just HTTP -- many other naming schemes, like LSID
for example, have systems for getting metadata about things.

<Zakim> johnk_, you wanted to ask why metadata is different than
"data"?

jar: I wanted to mention the HTTP 303 Redirect case, as an ad-hoc
protocol which has emerged from the Linked Data story.

<jar> TBL: want the tag to support the Link: header

<jar> ... doesn't want anything to threaten that

<masinter> doesn't understand why we need the TAG to support the
Link header and wants Tim to motivate that

<jar> jk: How is metadata any different from data [in the way it's
treated]?

<jar> timbl: What its access control is, how to edit it, all sorts
of things you want to know about an IR... we need this

<jar> timbl: Enables new functionality. A growing area.

<masinter> are you convinced the Link header meets the requirements
for all of those applications?

<jar> timbl: doesn't want to get too philosophical about this -
top-down is dangerous

<jar> ... important for the TAG to do because it's glue. A little
thing that will have a big effect.

<masinter> for example, is link header really the right way to
deliver access control information?

<jar> noah: How urgent?

<masinter> is prospective sending of 'Link' header a requirement for
sending access control information for applications that don't care
about access control?

<masinter> for example

<jar> timbl: We need to make sure the Link: draft gets reviewed,
make sure it gets moved along through process

<jar> ... Also we need to make an architectural recommendation

<jar> masinter: I'm not convinced of the goal.

jar: I brought the link header draft to the TAG.

<jar> (noah had asked about the history of the issue)

<noah> Proposed ACTION to Ashok: Keep an eye on progress of Link
header draft, report to TAG, warn us of problems.

Larry: I am not sure with the phrasing of the action that the HTTP
Link header should be followed.
... We do we need this? for ACLs? maybe we shouldn't use it?

jar: We could work on use cases.

<Zakim> ht, you wanted to ask about authority

<masinter> i believe the requirement is important. I'm not sure the
requirement is well articulated, and I'm even less certain that the
proposed mechanism satisfies the requirement.

ht: I liked what someone said about the suggestion that we need an
architecture for the data - metadata relationship.

<noah> ACTION: Ashok to Keep an eye on progress of link header
draft, report to TAG, warn us of problems (ISSUE-62). Due 8-1-2009
recorded in [15]http://www.w3.org/2009/06/24-tagmem-irc]

[15] http://www.w3.org/2009/06/24-tagmem-irc

<trackbot> Created ACTION-281 - Keep an eye on progress of link
header draft, report to TAG, warn us of problems (ISSUE-62). Due
8-1-2009 [on Ashok Malhotra - due 2009-07-01].

<jar> ht: Authority is fundamental to any metadata architecture

ht: Authority is fundamental to metadata in a way that it is not
fundamental to the ordinary web. [sic]

<DanC_lap> action-281 due 1 Aug

<trackbot> ACTION-281 Keep an eye on progress of link header draft,
report to TAG, warn us of problems (ISSUE-62). Due 8-1-2009 due date
now 1 Aug

<jar> ht: Link: is a response-header, not an entity-header ... this
makes the authority chain clear

<masinter> I agree the issue about authority is fundamental to
metadata architecture; not sure if it is more or less important to
ordinary web, but we understand web authority better

<jar> ht: this is different from putting it in the content

<johnk_> +1 to Larry - not sure how this isn't an issue for the
"ordinary web" too

<jar> ht: The server and the page provider are different principals
in this scenario

ht: If you get a document and the document contains link elements,
then the authority chain is clear, but if I get an HTTP link in my
case at Edinburgh then I don't necessarily have anything to do with
it.

<jar> john: another confused deputy problem

<jar> dan: No, it's not, just a bug

<masinter> how to distinguish between HTTP header metadata and
entity content metadata and the relative authority of them is an
architectural question

<masinter> ((wonder if there's some 'cascading' along with 'CSS'
that are cascading metadadta authorities))

<jar> timbl: We haven't talked about how delegation works inside a
web site.

<jar> ... This would be a new piece of work.

<masinter> ((wonders if appropriate to talk about XMP))

<jar> ht: But when we start to talk about metadata, it starts to
become much more important (it = the question of who the authority
is)

<masinter> ((relationship to content type sniffing?))

<masinter> ((WebDAV has protocol for managing 'metadata', doesn't
it?))

<jar> timbl: To build a system that treats Link: and <link> as
having different trust models compared to the data, would be to
assume stuff about the internal social workings of the site as
publishing agency

I realize Tabulator does absorb both, and does track the difference
in provenance, but does trust them to the same extent.

<johnk_> The "link header" is already a framework for links, not
just about the Link HTTP header

ashok: Let us get the Link header standardized so people can ge
things going.

<masinter> ((want to put in a pitch for embedded metadata))

<jar> ((embedded is always better than Link: **all other things
being equal**))

<Zakim> masinter, you wanted to put in a picth for embedded metadata

<noah> NM: Do we need to follow up on use of HTTP redirection in
addition to link header?

((You owe me $2M **all other things being equal**)) :-0

<noah> AM: Don't think there's more we need to do at this time.

<jar> I would put trust, authorization, authentication in a bucket
with access. maybe broaden the issue.

Larry: I think there is a question in the metadata architecture,
what do we recommend to people, for the priority of embedded vs
linked vs third party metadata ...

<jar> -- Eran has an answer to this.

Larry: People have the possibility of dealing with metadata from
multiple sources.
... We'd like two agents with the similar trust model to arrive at
the same concludion.
... So if you use a link header, for example, does this mean you are
overriding the other embedded data?
... I know a lot about embedded metadata, spend the last couple of
years working on it, and on the metadata for compound objects built
out of many other objects.
... When I come to thinking about metadata, the authority issues are
more prominent for me than with the web in general.
... In lots of the web, I think authority is a second priority.
... Authority on the web is more obvious for the data.
... Content type sniffing is wrong and dangerous here as everywhere.
... Is there a place for cascading, where i can override some but
not all of ithe data.

<jar> [jar would like to modify his previous remark, far above,
about entity-headers. i think ht was talking about the entity-body,
not the entity-headers.]

LArry: I also would put into the architecture the various places
wher metadata could be found.

<Zakim> johnk_, you wanted to mention text/plain and Link header

<masinter> ((or else put the metadata in the link itself))

jk: One use case is for plain text documents which don't have the
ablity to carry metadata. The link header is part of what Eran is
writing up as something much bigger.

<Zakim> jar, you wanted to talk about archiving of <link>-containing
documents vs. Link: and to say that the link:/<link> distinction is
important (in a practical sense)

jar: It would be illustrative of the tension betwen link element and
link header if you can focus on this question.
... I came to the conclusion that there are different entities
making these statements. Yes, one might not want to think about it,
but it does make a difference.
... You may archive an old verion of the ocument at a new URI.
... You rev it because the link elment is wrong.
... One thing you might say in archived metadata would be correct
metadata stating that that the link element is wrong.
... On serious archival situations, this has the potential to be
important.
... This is useful to just note they are coming from different
sources.

<johnk_> Making decisions about authority requires the ability for
the recipient of the data to be able to reasonably authenticate the
authority

<noah> TBL: There are lots examples where different people are
responsible for that information. Sometimes one or the other is easy
to access.

<jar> Re <link>/link: conflict we have three 'answers' on the table:
Tim/Dan, HT/JAR, and Eran. Eran says sources *must* agree

<noah> TBL: The situation where you archive specifically because
something was in error is a bit of a problematic path to explore.

<jar> timbl: LM, it's interesting that you think authoritativeness
of metadata is more important than authoritativeness of data

<masinter> I don't

<noah> TBL: Responding to Larry, I note that you are more concerned
about the "authoritativeness" of metadata than of the data. I can't
support that distinction. Both are important.

<masinter> Actually, "authority" is metadata.

<noah> TBL: Lots of data on the Web, such as banking, drug data,
etc. is itself important.

<noah> TBL: We can ask some useful questions: 1) how can I get
metadata specifically from the source of the data and 2) how can we
access (publish? -- not sure which Tim emphasized) 3rd party
metadata.

<noah> TBL: How does Henry find out that Dan has "tweeted" about
him? One answer: twitter.com sends an email saying "look who tweeted
about you"

<jar> careful: metadata attached to the URI is not necessarily
metadata attached to the resource (i.e. metadata and resource might
have different "owners")

<Zakim> noah, you wanted to respond on archived documents

<johnk_> noting content-centric networking work of Van Jacobson in
this area -
[16]http://en.wikipedia.org/wiki/Content-centric_networking

[16] http://en.wikipedia.org/wiki/Content-centric_networking

Noah: (Yes, archiving something and saying is is incorrect is a
fringe issue)

Danc: (yes, -- suppose you archive an old price list -- you don't
want people to believe it -- this isn't a metadata issue only)

Larry: "Authority is metadata". You can think of authority as
metadata [sic]

<johnk_> see content-centric networking, again ;)

Larry: the mechanism by which one dicovers and reasons about
authority is in general metadata.

<jar> how authoritative is the metadata? -- that would be
metametadata

jar: I don't know how the TAG could be involved in metadata formats.
... W3C has been promoting a particcular way of doing it, base of
standards.
... The punctuation has been provided by RDF, and the W3C story is
that communities will get together and make thei own vocabularies.

<masinter> ((should W3C endorse Dublin Core?))

jar: W3C has for example recently done SKOS, but it does not have to
happen within W3C in general.

<DanC_lap> 22 Jun: WebKit destined to get its own content sniffer
[17]http://sideshowbarker.net/2009/06/22/webkit-sniffer/

[17] http://sideshowbarker.net/2009/06/22/webkit-sniffer/

<masinter> ((media annotation is working on vocabulary))

jar: Every database you go to has a different vocabulary for
bibliographic data.. maybe people will fix [this] if it is a
problem.

<Zakim> johnk_, you wanted to now mention content-centric
networking, link to the capability discussion yesterday

<jar> embedded metadata is always better than out-of-doc *all other
things around metadata being equal*

jk: In this conent-centric networking concept (Ted Nelson and Van
Jaconson), they are trying to tackle this, and there is a link to
the capability issue
... in that the separation of data and metadata is a security issue.

<masinter> ((PDF/A ISO 19005 uses embedded metadata using XMP))

<Zakim> masinter, you wanted to talk to metadata formats

Larry: On vocabularies, these are related to formats.

<DanC_lap> (I think the POWDER spec ended up endorsing DC... or was
it FOAF)

Larry: Vocabularies: should W3C endorse Dublin Core? (I was called
the "Naysayer of Dublin")

<jar> lm: embarassed to say I voted "no" on all dublin core
attributes, but since recanted.

<jar> lm: it would be worth looking at w3c groups working on
vocabularies

Larry: I think the Video Annotation people are working on vocabs for
audio and video

<raman> calling zakim

Larry: I have worked on XMP, which has three parts, the format, the
vocab, and the method of embedding the format in an arbitrary
document.

<noah> Raman, we're talking about metadata. I'll dial now.

Larry: The format is a non-current profile of RDF. It is however
well deployed.
... There are other vendors using it.

<noah> Raman: please note that the agenda at
[18]http://www.w3.org/2001/tag/2009/06/23-agenda has been updated.

[18] http://www.w3.org/2001/tag/2009/06/23-agenda

<noah> I expect we'll break for lunch shortly.

Larry: There are ways of embedding it in most media formats. There
are some formats for which that is a problem, which leads to other
ways of linking.

<noah> Raman: After that, we'll be discussing a significant proposal
for TAG focus on AWWW for Applications. We will start refining a
proposed Table of Contents. Should be around 1:15 PM our time, so
10:15 AM your time, OK?

<jar> timbl: Being unable to squish it into the content is not the
reason it's good to use a Link header.

<masinter> TimBL: Link header overrides embedded metadata even if
it's present, it's more current, more authoritative.

<jar> ... e.g. the server may just know better. May have access to
list of versions, etc.

<noah> Also, Raman, though it's not in the agenda yet, I'm planning
to have our last session (4:15 our time) be the TAG logistics
session. Scheduling future meetings and summer telcons.

An example of something medata with link header is
[19]http://www.w3.org/2007/ont/unit

[19] http://www.w3.org/2007/ont/unit

<Zakim> timbl4, you wanted to say HTTP level data is sometime a
first resource because it really is authoritative.

<Zakim> timbl, you wanted to talk about W3C doing vocabularies

<masinter> [20]http://www.w3.org/TR/2009/WD-mediaont-10-20090618/

[20] http://www.w3.org/TR/2009/WD-mediaont-10-20090618/

<masinter> "Ontology for Media Resource 1.0"

<jar> timbl: W3C staff is asking how much W3C should be involved in
ontology development

<jar> ... provide an environment? stimulus? process? tools?

<jar> timbl: What is the level of agreement between dspace, fedora,
eprints (re bib format)?

<jar> dan: ... re vcard & html5 ...

jar: As a consumer, I think it would be really nice to have some
agreement on some basic vocabularies, such as in bibliographic data.

<jar> ... but it's not different from any other standardization
tarpit

Noah: I have necome awrae of the tendency of the TAG to get to a
state in which we have become aware of the fact that it might kinda
be useful to do something.

Larry: I have an action to open up an issue, and this discussionhas
been very informative.

Noah: I will need to understand what the TAG should do in this area.
Shoiuld we look at whether W3C should get into ontology
stndardization?

<masinter> standards provide for extensibility but also a "common
base" that everyone agrees that, no matter what else they did.

<noah> LM: I will, in my framing of the issue, try to set out
options for what if anything the TAG should actually do about this.

<masinter> Three issues: access, format, vocabulary

jar: I haven't been sure before about what the TAG could do, but now
I feel we should have a metadata architecture. It is also something
I find it very easy to justify working on as it is key to Science
Commons.

<jar> & trust/authority too

Noah: Would this be useful use of TAG time?

[general positive rumblings]

RESOLUTION: We want to start work on metadata in general, including
access and formats.

<scribe> ACTION: Jonathan to draft a finding on metadata
architecture. [recorded in
[21]http://www.w3.org/2009/06/24-tagmem-irc]

[21] http://www.w3.org/2009/06/24-tagmem-irc

<trackbot> Created ACTION-282 - Draft a finding on metadata
architecture. [on Jonathan Rees - due 2009-07-01].

<masinter> would include working groups working on vocabularies,
link access, RDF/A

<masinter> audience should

Ramin: We should know who the audience is for this, and how we are
going to have an impact with the work.

<jar> raman: Who is the audience? How will we have apositive impact?
make sure that's answered

Jar: I can think of a number of people who would eat this up.

<jar> action-282 due 2009-08-31

<trackbot> ACTION-282 Draft a finding on metadata architecture. due
date now 2009-08-31

<ht> _Proofs and Refutations_

<ht> by Imre Lakatos

<ht>
[22]http://www.amazon.com/Proofs-Refutations-Logic-Mathematical-Disc
overy/dp/0521290384/ref=sr_1_1?ie=UTF8&s=books&qid=1245863853&sr=8-1

[22]
http://www.amazon.com/Proofs-Refutations-Logic-Mathematical-Discovery/dp/0521290384/ref=sr_1_1?ie=UTF8&s=books&qid=1245863853&sr=8-1

<masinter> scribenick: masinter

Versioning and HTML

<Ashok> Noah: I'm being encouaged to consider the HTML5 draft.

<Ashok> ... how can we influence the draft?

<scribe> ScribeNick: Ashok

<noah> I agree with the suggestion that we should focus on how to
positively impact the HTML work.

Noah: If I said I'm pessimistic, we will not have influence on HTML
work, would someone push back?

<raman> calling zakim

LM: It is a good general discussion; even if we do not have
influence on HTML5, it may influence other WGs.

<noah> Will dial. Note that agenda has again been revised, due to
last minute change in Tim's availability. See posted agenda.

<raman> all by myself on zakim

LM: we shoud approach from POV that, if they are right, how would we
modify the versioning finding?

<noah> Raman, see note above on schedule change: now discussing
versioning

LM: Also possible we may have a positive effect on HTML5 itself.

JK: I agree w/Larry

<noah> TBL: We should explain that HTML 5 is using a different
pattern.

TimBL: It would be OK for TAG to agree with our TAG-SOUP conclusions

Noah: LM is talking about version identifiers

HT: Tim is also talking about version id's

<Zakim> ht, you wanted to support the proposition wrt the narrow
goal

Raman: Does the exception apply also to Web Apps? Where does it end

ht: +1 to emphasize certain aspects of what Larry said. This is a
narrowly scoped proposal.
... pros and cons of the space in which the decisions about version
id's fall
... we will end upo with costs and benefits
... there is no single best practice... that's the point

Noah: We did some work on XML versioning
... now moving to HTML space ... specifically about version
identifiers

LM: Consistently in HTML WG when general priciples are raised the
questions comes back "can you justify this is a good principle"
... we need to explain why version id's are a good idea or not

Noah: Proposal --- to do a balanced analysis of pros and cons of
version id's and who would be influenced by it

Dan: That's a pretty high bar but 'yeah'

<masinter> suggest removing 'balanced'

LM: As balanced as we can be

Dan: the challenge I see is to do the macroeconomic analysis well

<masinter> I think, for example, that we will need a framework for
talking about versioning and APIs

Noah: I would like to do some teaching on this
... please notice these points of confusion

JR: This is interesting to me because this is a puzzle. If I learn
something I would be interested in telling someone else.
... it seems valuable and seems hard.

<masinter> Ashok: Noah is looking at this from the filter of past
versioning work, and that didn't work out very well. Ashok thinks
this is different, more specific.

Ashok: This is different ... only for HTML and only the version id
proposal.

Noah: So do we start some work in this area?
... seems like we have consensus to do so.

<johnk_> what is the role of
[23]http://www.w3.org/2001/tag/doc/versioning-html/versioning-html-2
0090611.html?

[23]
http://www.w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html?

Noah: Larry, what steps would you propose?

LM: Yesterday I went thru the outline of the document we wrote. It
would be good to go thru it again and get feedback on it and then
plan what to do about the document.

Noah: We said we would work on version id's. The document
title/abstract is very broad.

LM: Our success criteria shd be if we answer whether there shoud be
a doctype in HTML5.
... I think we will come up with something broader.
... Look at last sentence of second para.
... I accept the discussion should be narrower

JK: The start of the doc provides context. The rest is about version
id's

LM: The intro promises more than the document delivers and what we
are interested in. We should edit the title.

JR: What about the other issues re. versioning?

Noah: The language versioning issue remains open.
... David Orchard will publish his doc under his own name.
... and we would go quiet about versioning for a while.

JR: Asks about other versioning issues like distributed
extensibility and the attitude of WGs about extensibility

LM: Let's focus on version id's first ... and for HTML5.

(reviewing versioning document)

LM: The terminology section we talked about yesterday. There was
some discussion about how to go about talking about what a language
is.
... HTML5 says a language is what people use not what's written in
the spec.
... this is an important distinction.

Dan: I would rather not see an upfront terminology section. I would
rather define the terms in context.

<Zakim> noah, you wanted to discuss specifications vs. languages

<masinter> i think that's editorial (whether there's an up-front
terminology section).

LM: Needs to say which language is being versioned

Noah: I'm not fond of this phrasing about what language is.
... language is a set of texts and what the texts mean

LM: What's missing is the distinction between language and dialects
... how languages are used.
... Languages apply to a community that agrees to speak it
... ((Discourses on languages and their implementations, an versions
thereof.))

JR: I think that's very important. I was using a single word for
languages that are specified and languages as they are spoken.

LM: Languages have constraints and permissions
... implementations have behavior.

Noah: Its useful to separate the spec of language from what
implementations do.

<masinter> i think it's important to talk about 'communities' of
*implementations*

<DanC_lap> (one of the reasons I hate up-front terminology
discussions is that they result in this sort of
let's-discuss-everything-at-once discussions. a list of terms and
their definition is the end of the game, not the beginning.)

Noah: describes Purchase Order languages
... there are different users with different uses in mind
... these could be spelled out in different specs

LM: We don't share assumptions
... communities are communities of implementations
... there are constraints and permissions exhibited by language
specs, and behaviors exhibited by implementations

Noah: Example: HTML language and 2 browsers -- traditional and voice
... there will be a 3 specs: langauge spec and 2 implementation
specs

<masinter> ((noah asks for distinction between spec, implementation
spec, implementation))

Noah: pl. explain how you would tell that story

LM: I am separating implementation from an implementation spec. You
cannot 'define' an implementation except by the implementation
itself.

<johnk_> I think (but don't know) that Noah meant that there were
two kinds of spec in this example - language specification, and
implementation class specification.

<noah> Yes, and in particular, one should try to avoid leakage of
implementation specifications into language specifications (at least
most of the time)

<johnk_> implementation specification, or implementation /class/
specification?

LM: ((describes an example of implementation spec and discusses
refining specs that would have a narrower domain of applicability))
... Part of issue with HTML5 is that level of specificity is
detailed enough to make you wonder if it does not inappropriately
specify behaviour of other agents

Noah: They would say that hidden within this is an author spec

<masinter> it isn't hidden

Noah: I don't understand their lack of recognition of other agents

LM: The charter says to produce a spec that applies to all agents;
behavior of compliant browers is specified, and other agents want to
be compatible with browsers
... Calling it anything other that a technical spec of HTML would be
to insult it.

<noah> Raman, if youi're curious, we're still waiting for Tim to
return

<masinter> question about distinction between language
specifications having constraints and permissions, while communities
of language implementations have behaviors

HT: This is a useful distinction berween spec and implementation
... I was thinking that all interactions are 1 producer to one
consumer. Or 1 producers and many consumers.
... rare to have many producers and 1 consumers.

<masinter> a specification is an attempt to document or propose
constraints and permissions to communities which agree on behavior.

HT: in HTML very small number of consumers ... say 4

Noah: disgrees saying users are people in front of the screen

HT disagrees

<masinter>
[24]http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

[24] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

<Zakim> ht, you wanted to mention the cardinality of consumers point

Noah: Argues that users are humans not browser vendors
... Assume you are right. What do we conclude from that?

HT: I want to go back and see if this understanding changing
anything

LM: IE on Windon Windoes and IE on Mac etc are differents agents. So
many more than 4 users

<Zakim> ht, you wanted to give way by an order of magnitude, maybe
two, but not much more

HT: OK. It's in the hundereds not in the millions

<Zakim> DanC_lap, you wanted to suggest 'critical mass of the
market' as a way to distinguish "4 major browsers" from the long
tail of tools. The long tail can't wag the dog ;-)

Noah: Do microformats change the equation?

<masinter> level of interoperability is an important concept

LM: I will take an action to respond to feedback on this document

Noah: Start a finding?

<DanC_lap> ACTION: Larry update document on version identifiers
w.r.t. Cambridge June discussion [recorded in
[25]http://www.w3.org/2009/06/24-tagmem-irc]

[25] http://www.w3.org/2009/06/24-tagmem-irc

<trackbot> Created ACTION-283 - Update document on version
identifiers w.r.t. Cambridge June discussion [on Larry Masinter -
due 2009-07-01].

Noah: on version identifiers

<DanC_lap> action-283 due 24 July

<trackbot> ACTION-283 Update document on version identifiers w.r.t.
Cambridge June discussion due date now 24 July

LM: Moving on with the document
... I want to get more history on doctype

Dan: I don't think DOCTYPE is an interesting design. Only design is
version attribute on HTML5

<jar> jar's advice to LM: please treat consumers and producers more
symmetrically. my comment "why constrain only consumer behavior" was
an experiment and now i think it's better formulated as constraints
(or behavior or practices) on both producer and consumer.

LM: What are in-band global version identifiers; try and postulate
possible version changes that may happen for HTML 6 and a
game-theoretic consequences of having the version Id's for HTML6
... cost/benefit tradeoffs

Noah: Summarizes
... we decided to move forward with this work with focus on version
indicators.

JK: So we shd review doc and send comments?

LM: Yes

Web Arch for Applications

Noah: We added this based on yesterday's discussion

<masinter> Noah: Tim said: we have an arch for web of documents.
What is the architecture of the web when you're sending and running
applications locally?

<DanC_lap> scribenick: masinter

Noah: Is this something we want to bite off -- does this become a
new chapter of AWWW? Does it influence the current document, etc?
... first concentrate on content. Let's imagine what we're going to
do is add another section of the AWWW

Put together what a table of contents would be. From that we can
debate whether this is a good focus for the TAG's work.

<DanC_lap> "Draft Standard â 24 June 2009"

<DanC_lap> --
[26]http://www.whatwg.org/specs/web-apps/current-work/multipage/

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

<noah> [27]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

[27] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

((Discussion about title and name of what we're working on))

TimBL: HTML5 is a really strong priority for TAG to look at it
... If TAG members to see things wrong with HTML5 we should say
something about it. Otherwise "bad things happen because good people
don't act on it"

((discussion of the 'iCalendar' issue, for example))

<noah> Updating live copy of TOC @
[28]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

[28] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

<noah> timbl: Can we spend 1/3 of our energy on HTML, 1/3 on Web
application architecture, and 1/3 on other things?

Noah: proposes we look at Web applications architecture, then come
back and answer this question
... Proposed table of contents again
[29]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

[29] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

Question is whether TAG will take this on as a major work, of the
same scope as AWWW?

What are the parallels to the 'regular web' and how are things
different or not?

Ashok: point out HTML5 has a database interface (which he thought
they had no business spelling out, thought it would be in the form
of SQL calls.)

<Zakim> johnk_, you wanted to suggest we need to come up with a
unified statement that encompasses the laundry list curently written

Ashok: We ought not go in and follow working group, not sure we
should interfere.

jk: if I look back to the original webarch, we extracted general
principles, resources & representation, we said "Use XML" and gave
good practices
... I'm saying a little more: what is the unified statement we'd
make about this laundry list of specifications; is there anything we
can say about JavaScript and CSS and HTML5?

ht: somehow Noah's TOC document got away from the whiteboard
... i think it's important enough that it's worth trying to do it
... primary energy of those behind HTML5, people's sense of how they
want to use the web and the net is a distributed application
platform, but not suprisingly it's not going very well

((discussion about WebAPPS vs. HTML5))

<noah> Raman, do you want to be on the queue

ht: all we might wind up doing is try to give guidance to HTML5 for
webapps arch

danc: trying to find history of calendar stuff, found offline
storage
... ((discussing offline storage & webapps vs. html5))

jar: has typed in everything on the board and organized

<DanC_lap> TVR: this all made sense until we started talking about
it being separate from HTML 5;

<DanC_lap> ... these are all tangled up, as Henry said

<Zakim> DanC_lap, you wanted to note HTML WG's separate WD on
database API and to note
[30]http://www.w3.org/TR/2008/NOTE-offline-webapps-20080530/ and to
promote "...no business..." to an

[30] http://www.w3.org/TR/2008/NOTE-offline-webapps-20080530/

jar: when this discussion about CORS was going on, that ended when
Anne came to an impasse

<Zakim> noah, you wanted to talk about HTML 5 vs. what we do

Noah: perhaps he's piling on. We have to go into this that part of
our job is to influence HTML5. But we should try to set out is to
set out principles and advantages in a way that people would have
trouble disagreeing with.
... for example, with URI finding 'if you use a URI for everything,
you'll be able to link to a URI'
... doing that when informed by HTML5 is fine.
... People have not disagreed about whether you get some advantages
or disadavantages with a certain pattern, they've disagreed about
whether the advantages are important.
... What's going through my head is that really undertaking this the
way Tim said is a big focus for us.
... What I hear is somewhere between positive and real enthusiasm.

Raman: if you start out to be a multi-year exercise, we will fail.

Noah: how do we build something like this? Often the way we've used
findings are details or summary.
... keep working on the outline, do that in the form of findings and
notes.
... maybe in parallel and appoint an editor or two.

masinter: suggestion to take each of the topics and write up 'what
is the question', and use that as a way of motivating discussion.

Noah: put that up as a live outline. as people discover new things

((discussion about whether it's a wiki or cvs or form))

jk: it would help if we could write up a statement that says: "web
applications already exist, they are things that are delivered from
a server by a client", what happens? Most of these issues revolve
around mash-ups?

<noah> Tim earlier said: Can we spend 1/3 of our energy on HTML, 1/3
on Web application architecture, and 1/3 on other things?

jk: Mash-ups are an example of an area where the issues are most
clear

((discussion about state and multi-parties applications between JK
and TimBL))

<raman> lunch beckons. I'm off

((Discussion about offline apps vs. Comit and plumbing and issues
around that.))

TimBL, JK, Noah

Noah: How much of our traditional terminology applies? E.g., web
server on phones?
... Want to push back, throw out ideas for how we organize things.
... Question about this organizing findings and notes, unified
document as a whole not sure
... continue working on drafts and findings we've already heard
... take a list like this (the TOC), tune it up; under each one, try
to catalog what the issues, pain points, and opportunities, build up
over time.

<johnk_> it would help if we could write a statement that says "web
applications already exist - traditionally they have been delivered
by an (HTTP) server and rendered by a (browser) client. Today, web
applications often have multiple communicating parties, and the
client often acts as more than a rendering agent. What are the
architectural issues?"

Noah: at various times we will decide

Jar: our charter is to produce architectural recommendations, not
finding
... it's been 5 years, we should be working on one

<johnk_> ((by the way, not too wedded to the statement I've made,
but would like to be able to make clarifying statement of some kind
for this work))

danc: building a web application, got into permission problems.
cross origin was most difficult element for ordinary programmer

ht: (side note) range of conflicting responses to our message to
Art. various players have responded.

Noah: how to fill in this outline? would like to wrap this section?
... will get people assigned to this
... I will come back to get the next round of work, writing down
briefly a few line items with a few sentences or a paragraph.

<scribe> ACTION: jonathan to flesh out the outline with as many
sentences as he can [recorded in
[31]http://www.w3.org/2009/06/24-tagmem-irc]

[31] http://www.w3.org/2009/06/24-tagmem-irc

<trackbot> Created ACTION-284 - Flesh out the outline with as many
sentences as he can [on Jonathan Rees - due 2009-07-01].

Noah: after break we will work on schedule

group picture

<DanC_lap> jar, re 1st party etc.
[32]http://www.downes.ca/post/38498

[32] http://www.downes.ca/post/38498

<johnk_> re: 3rd parties
[33]http://en.wiktionary.org/wiki/third_party

[33] http://en.wiktionary.org/wiki/third_party

<jar> I had been saying "second-party metadata" meaning metadata
coming from the origin (or the URI or the resource or the
representation). Dan has corrected me and I will henceforth call it
"first-party metadata"

reconvene

tag administration issues

<noah> Raman, we are discussing f2f scheduling

<ht> TV, you there?

<DanC_lap> we discussed summer telcons; noah has notes

<ht> Formal proposal to move 22-24 Sept TAG to 23-25 TAG

<DanC_lap> PROPOSED: to move Sep meeting to 23-25 Sep

<ht> Amy, any reason not?

<amy> s

<ht> 22 Sept is One Web Day

<DanC_lap> so RESOLVED.

Nov 2-6 in Santa Clara TPAC

<amy> the group would have to split days between Star (not the room
you're in) to Kiva (the one you're in now)

<DanC_lap> ah. I think we can deal with that, Amy

<amy> ok, if you like the room you're in, I can get you that for two
of the three days

<DanC_lap> cool. thanks.

<noah> Amy, we have voted to reschedule for 23-25 Sept. Would you
please move rooms.

<noah> Thank you!

<amy> ok, I confirm the rooms are moved

<amy> same basic procedure. I'll get catering, let me know if you
need a bridge/phone and any parking

<amy> i can send info on nearby hotel rates (w/ the MIT rate) if you
need later

<DanC_lap> ACTION: Noah make sure TPAC logistics are straight
recorded in [34]http://www.w3.org/2009/06/24-tagmem-irc]

[34] http://www.w3.org/2009/06/24-tagmem-irc

<trackbot> Created ACTION-285 - Make sure TPAC logistics are
straight [on Noah Mendelsohn - due 2009-07-01].

<DanC_lap> LMM: HTML WG meets Thu TPAC week

<DanC_lap> action-285 due 30 July

<trackbot> ACTION-285 Make sure TPAC logistics are straight due date
now 30 July

<timbl> [35]http://www.w3.org/2009/11/TPAC/

[35] http://www.w3.org/2009/11/TPAC/

discussion about schedule, not worth minuting

adjourn

Summary of Action Items

[NEW] ACTION: Ashok to Keep an eye on progress of link header draft,
report to TAG, warn us of problems (ISSUE-62). Due 8-1-2009
recorded in [36]http://www.w3.org/2009/06/24-tagmem-irc]
[NEW] ACTION: Jonathan to draft a finding on metadata architecture.
recorded in [37]http://www.w3.org/2009/06/24-tagmem-irc]
[NEW] ACTION: jonathan to flesh out the outline with as many
sentences as he can [recorded in
[38]http://www.w3.org/2009/06/24-tagmem-irc]
[NEW] ACTION: Larry update document on version identifiers w.r.t.
Cambridge June discussion [recorded in
[39]http://www.w3.org/2009/06/24-tagmem-irc]
[NEW] ACTION: Noah make sure TPAC logistics are straight [recorded
in [40]http://www.w3.org/2009/06/24-tagmem-irc]

[36] http://www.w3.org/2009/06/24-tagmem-irc
[37] http://www.w3.org/2009/06/24-tagmem-irc
[38] http://www.w3.org/2009/06/24-tagmem-irc
[39] http://www.w3.org/2009/06/24-tagmem-irc
[40] http://www.w3.org/2009/06/24-tagmem-irc

[End of minutes]
_________________________________________________________

Minutes formatted by David Booth's [41]scribe.perl version 1.135
([42]CVS log)
$Date: 2009/07/21 20:50:04 $

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

Text-only version of TAG F2F minutes of 23 June 2009

2009-08-10T13:45:30Z

A text-only copy of the minutes from the first day of the TAG's F2F
meeting in June, 2009 is attached.

Noah

[1] http://www.w3.org/2001/tag/2009/06/23-minutes.html

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

[1]W3C

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

- DRAFT -

TAG f2f

23 Jun 2009

[2]Agenda

[2] http://www.w3.org/2001/tag/2009/06/23-agenda

See also: [3]IRC log

[3] http://www.w3.org/2009/06/23-tagmem-irc

Attendees

Present
Tim Berners-Lee, Dan Connolly, John Kemp, Ashok Malhotra,
Larry Masinter, Noah Mendelsohn, Jonathan Rees, Henry S.
Thompson

Regrets

Chair
Noah Mendelsohn

Scribe
Henry S. Thompson, John Kemp

Contents

* [4]Topics
1. [5]Admin
2. [6]W3C Work on APIs
3. [7]Language Versioning and HTML
4. [8]Web Application State Management
5. [9]Javascript Security
* [10]Summary of Action Items
_________________________________________________________

<ht> ScribeNick: ht

<scribe> Scribe: Henry S. Thompson

Admin

NM: Scribe duty: Tu: HST, JK; We: TBL, LM; Th: AM, ???

<scribe> Agenda: [11]http://www.w3.org/2001/tag/2009/06/23-agenda

[11] http://www.w3.org/2001/tag/2009/06/23-agenda

NM: [intro to meeting, see
[12]http://www.w3.org/2001/tag/2009/06/23-agenda#F2FReview]

[12] http://www.w3.org/2001/tag/2009/06/23-agenda#F2FReview

LM: Swap first two Thursday morning a.m. sessions?

NM: Yes

[Language Versioning vs. HTTP Semantics]

W3C Work on APIs

[13]http://www.w3.org/2001/tag/2009/06/23-agenda#APIs

[13] http://www.w3.org/2001/tag/2009/06/23-agenda#APIs

NM: W3C is on the verge of taking on standardization of APIs

<masinter> w3c is in the middle of standardiation of APIs

NM: Some folks asked whether W3C should be doing this
... and maybe the TAG should contribute to this discussion

<noah> ac2 n6ah

LM: WebArch and our findings mostly/entirely are concerned with
static stuff
... so this at least appears to be a delta

JK: W3C has some API-type standards already, e.g. the DOM, but the
TAG has not said anything about it/them

LM: Wrt the current chartering decision, we don't have a role to
play in the decision as such
... but if/when they do, we need to consider whether there are arch.
issues there, which is now officially part of "The Web" as the
Consortium addresses it, which the TAG ought to address

NM: So the TAG ought to line up its investments with areas of
interest to the W3C
... What would that mean wrt e.g. device APIs

LM: We should examine our current findings to see whether they
can/should be adapted to cover APIs, and
... as we do new stuff, we should keep APIs in mind

TBL: Yes, obviously -- W3C does APIs, the TAG should include this in
their remit
... The WebApps platform is more and more important, and clearly
APIs are important there
... So, yes, definitely they're in scope
... Going on to say WebArch 2: The Web as a Computing Platform --
I'm not sure

AM: What direction to we provide to WGs/Chairs -- should it be
different? How do API standards get tested? How ensure they are
valid/representative? Is this different for APIs?

NM: Consider drawing a circle within the <canvas> TAG -- the rule of
least power clearly relevant here: contrast sending JS which says
"draw a circle" vs. sending an SVG circle tag
... The JS that comes over the Web is clearly in scope, less so the
kind of local scripting which e.g. manages my desktop

LM: I had a long discussion about <canvas>+JS vs. SVG -- declarative
vs. imperative

<Zakim> noah, you wanted to talk about rule of least power and
canvas tag

LM: For many delivery mechanism, imperative mechanisms are
inappropriate, e.g. in HTML-marked-up mail
... But for other contexts, e.g. a drawing program within a Web
page, imperative is much more appropriate
... Convenience and performance weigh heavily in this case

NM: RoLP is a bit like 'SHOULD' -- there's a tradeoff -- you get
convenience and performance, you lose transparency

TBL: Little declarative languages emerge in this context
... and sometimes get standardized

JR: Contrasting SVG with JS - you start with a weak==declarative
language [HTML], and build out by decorating with JS, there's a kind
of graceful degradation, whereas with JS, [if you start it] with you
are stuck from the beginning, there's no way to move the other way,
from the strong==imperative language to something weaker

<jar> (unless you make javascript safe, by changing it a little bit)

NM: We don't want to just rehash the RoLP, but do we need to call it
to people's attention?

<noah> Yes, and the question is, what else if anything should we do
to "helP" the community that's investing in APIs at W3C?

LM: I don't think people care much about LoRP, insofar as they think
of the Web as entirely made up of servers and browsers

<jar> (re my parenthetical comment, larry is pointing out that even
a safe javascript is not that useful, since it's not declarative)

LM: but once you start _analyzing_ pages, or you need/want graceful
degradation, you have no chance with an imperative language
... So API evolution/degradation/extension that we have the most to
say, wrt both balancing declarative vs. imperative, but also given
an imperative API, the versioning/extensibility should be taken
seriously, and we can help here

TBL: So, yes, endorse LoRP, but when we've got APIs, yes, more to be
said as well: e.g. modularity
... So, given that JS modules don't have a packaging system == a URI
as a name, there's a problem
... A good web-addressable JS package system would be a great thing
... relates to trust

JR: [scribe missed]

JK: What about WebIDL -- allows some declarative statement of
dependencies?

NM: There's no import or anything required to use <canvas> -- either
it works or it doesn't

DC: CSS selectors are a better example

<jar> - I wanted to draw connection to "self-describing web"
finding. Can one go to an HTML page containing javascript, and learn
*without running the code* what its dependencies are? (this question
may be simple ignorance) i.e. can you nose-follow effectively
without execution? - because this might help with extensibility and
graceful degradation.

NM: Some of these are built-in, sometimes you need to try to import
a JS library

<DanC_lap> (my "are a better example" is a response to a pattern
timbl observed that went by too fast for the scribe or something)

NM: and sometimes you can use one as a fallback for the other
... Self-describing Web applies to this case as well, as far as I
can see
... JS interactions are as normatively specified as anything else

JR: But you can't (easily) tell what any given JS will do except by
running it

<masinter> wonder if AWWW has enough 'roles' for participants in the
web, including authoring, analysis, search engines, proxies,
translation gateways, etc... because these are important agents for
programs written in JavaScript

TBL: Consider the case where a small module pulls in Google Maps,
which has its own module structure and conventions

JR: I don't think you can even tell if that happens

JK: You can check dependencies without running the code

<masinter> and authoring tools

TBL: Not inside Google Maps, because they do their own
... There is no standard way of declaring, or therefore of
detecting, JS dependencies on the Web
... So if you try to combine Yahoo Calendar and Google Maps you get
into trouble
... You can't do a JS import from inside JS

JK: So they cheat, pushing a <script source=...> tag

<johnk> Tim said "cheat", not I ;)

<DanC_lap> (raman showed me an import technique that doesn't use
<script> insertion. I didn't study it well enough to remember the
details.)

LM: The problem only arises when you have agents that want to
interact with e.g. script-containing pages _without_ just running
them
... AWWW doesn't say enough (anything?) about agents like this:
spiders, dependency checkers, ...

HST: Tool to download a page and everything it needs to run locally
w/o web access

AM: [scribe missed]

NM: TBL, are you asking if the TAG should take on the
standardisation of dependency declaration for JS?

LM: There's a lot out there already, we don't have to originate this
work
... You can't tell what a program will do w/o running it, but you
can make some of it, e.g. dependencies,
available/accessible/declarative
... So e.g. our programmers have to adhere to conventions so that
raw strings are never used as such, they have to be indirected so
that localization can happen systematically

DC: Two JS issues, modularity and same-origin
... ECMAscript WG has passed on modularity, I think
... but that is really in other people's hands
... Wrt same-origin, the best source for this at the moment is
Wikipedia
... we probably should lift what there is about that from the HTML5
spec., just as we lifted some things from the HTTP spec

TBL: HST was skeptical otr about the possibility that JS would be
made safe

JR: I put my comments in IRC above wrt JS/safety, and then retracted
them a bit following LM's comments

LM: Maybe something of the scope of the old QA activity, focussed on
declarative languages, might be necessary
... Is the QA precedent hopeful?
... If this pblm is too big about the TAG. . .

NM: Trying to see which way we go, I heard TBL say that maybe AWWW2
might be WebApps
... That's broader than just APIs, involves e.g. TV's draft,
security, etc.
... I heard LM say that AWWW didn't talk enough about [other] agents
... JS packaging came up, with the suggestion that we not do the
work ourselves
... Finally, the suggestion that same-origin deserves to be pulled
up to the Arch level

JR: We could issue as it were a Call for Proposals: We don't yet
know what it would mean for us to have Arch. Principles for WebApps,
but we know they would have to address the following requirements
... There's a difference between saying "We don't know how to do
this" and "This is out of scope"
... Saying "Either this is out of scope, or we have to do it" --
there is a third position, which is "We care about this, please you
do it"

TBL: AWWW v. 1 varied hugely in granularity - it's OK to say both
"WebApps are really important, be careful" and "Here's a very
specific recommendation wrt APIs: ..."
... compare "Use URIs" and "Don't use GET unless it's really a GET"
... So, e.g. "The modularity/packaging situation wrt JS really needs
to be improved" and some very specific detailed recommendation
... So we could draw up a ToC, with very variable depth

NM: So maybe will have a session at this meeting to explore a ToC

LM: I heard JR say we could try a document which was _not_ a
finding, but a tabulation of the issues, and our understanding of
them, and why they are important
... I think such a document would be very helpful, and we could do
it quite quickly
... with a goal primarily of raising awareness

NM: Scoped to Web Applications?

LM: No, scoped to APIs

<johnk> I will note though that there is a "widget packaging"
specification, which might be considered a solution to "javascript
packaging"

HST: I would prefer the broader scope, if possible: we have a
situation in which the browser is the _de facto_ distributed web-app
delivery platform, but it wasn't designed for it, and we need a
better one

NM: Procedural point -- do we need to track JS packaging? Is there
something we want to tell the community in this area in the short
term

JK: Is the Widget Packaging work relevant?

LM: I don't think so

TBL: Does it give URIs for package components?

<masinter> it might be relevant but it's a different use of the word
'packaging'

JK: No, but people have suggested it should

<masinter> yes the "widget:" URI scheme is a proposals

<johnk> and there were other proposals which didn't involve a new
scheme

<johnk> widget URI scheme is _not_ global in scope

LM: I think we should engage in discussing the issues, before we
decide where to go with them

<johnk> IIRC, Stuart worked on this quite a bit

JK, yes, he did

AM: Thinking about how we publish the AWWW2 ToC

<masinter> suggest TAG note "Architectural Issues for APIs in the
Web Architecture"

<masinter> and that we try to publish a note in 3 months

<masinter> start with APIs and if we have more to say about other
parts of APIs

NM: So, back to the ToC -- scope this to APIs, or more broadly to
the web-app platform

<masinter> and that 'answers' aren't out of scope, but problems
first

HST: I'm happy to follow LM's suggestion and enumerate problems we
see, and decide the scope later, bottom-up

<Ashok> +1

<masinter> i'm happy to add other issues that relate to APIs but are
part of web applications

NM: There are things on the table which are important, which go
beyond APIs, but which are in this general space, about getting the
Web right for applications in general

LM: I don't want to rule webapps out of scope from the start, but I
want to be able to declare victory when we have a reasonable set of
problems outlined

<masinter> in fact, we could scope it by time rather than by
breadth: "Some Architectural Issues" and we declare success when we
have N months into it

LM: What about XAML and FSG (for Flex, at Adobe) which are hybrids,
there's a markup language which looks declarative, but which is
implemented by API calls

NM: The XAML stuff provides for declarative access to only a subset
of the API

TBL: Possible TOC:
... Declarative:Procedural::....
... APIS: Good Practices, ....
... Modules & Dependencies
... Security: Trust boundaries, Cross-site, Same-origin
... Client-side#URIs

DC: Geopriv?

AM: Don't we need an action to get this started?

NM: We'll come back to that in another session
... AM, any followup wrt geopriv?

<noah> I think we should add PRIVACY to the Possible TOC above

AM: We could ask the GeoLoc WG (W3C) to add some some explicit
discussion of privacy

TBL: How would that be different from the IETF work to date?

NM: Do we know enough to ask this question in a way which actually
provokes something specific?

<masinter> proposal: be clear that scope of privacy and security
issues is not limited to use cases that API is designed for, but
rather all applications which might reasonably use the API

NM: Someone prepared to take an action to draft input to the GeoLoc
WG?

TBL: Need to be willing to spend face time with the editors/chairs

LM: I'm heading to the IETF meeting in July, I will be happy to
liaise with the IETF GeoPriv there

DC: We could pbly talk with Matt Womer and Philippe Le Hegaret here
today

<masinter> with whoever is there

ACTION to Dan to propose concrete steps wrt GeoPriv after consultion
with W3C members/staff

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

trackbot, status?

ACTION Dan to propose concrete steps wrt GeoPriv after consultion
with W3C members/staff

<trackbot> Created ACTION-275 - Propose concrete steps wrt GeoPriv
after consultion with W3C members/staff [on Dan Connolly - due
2009-06-30].

ACTION Larry to take GeoPriv discussion with IETF forward in person
in July

<trackbot> Created ACTION-276 - Take GeoPriv discussion with IETF
forward in person in July [on Larry Masinter - due 2009-06-30].

[break]

Language Versioning and HTML

[14]http://www.w3.org/2001/tag/2009/06/23-agenda#naming

[14] http://www.w3.org/2001/tag/2009/06/23-agenda#naming

NM: We have both strategic and technical questions before us
... Our goal is to have a positive impact on the HTML WG
... I have doubts about whether we can achieve that
... Before we dive in, and we can mix the meta- and the base-level
discussion, but I don't want to proceed w/o _any_ thought to where
we're headed
... I'll leave it to LM to decide whether to drive forward a bit
technically before looking to how to sell the results

LM: The default action in the HTML5 WG will be that there will be no
version indicator
... some people, including Michael Champion, are uncomfortable with
that
... So we could come up with a TAG finding, qualifying WebArch, as
to what situations don't need or even want VIs
... and why HTML5 is one such
... That would help the WG

<DanC_lap> "A data format specification SHOULD provide for version
information." -- [15]http://www.w3.org/TR/webarch/#versioning

[15] http://www.w3.org/TR/webarch/#versioning

NM: I produced a blog entry which went some way in that direction
(see
[16]http://www.w3.org/QA/2007/12/version_identifiers_reconsider.html
)

[16] http://www.w3.org/QA/2007/12/version_identifiers_reconsider.html

LM: I think we are making some progress on understanding the
problem, going beyond the blog post, I think

<DanC_lap> note D Baron's essay
[17]http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.htm
l

[17]
http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html

DC: Some things I found helpful in moving towards accepting the WG
default position: current HTML version indicators are rarely correct
... David Baron's essay suggests VIs are counterproductive -- it
tells the story of how MSW version 8 has a complete version 7
implementation inside it
... MS can afford to do that, but most folk can't

<Zakim> johnk, you wanted to ask about what we call a "version
indicator"

JK: By VI you mean what? An explicit statement of version, or
anything which allows some agent to detect difference in versions?

DC: A specific flag that changes the interpretation of the entire
document

JK: Entire?

DC: In principle, yes

<DanC_lap> DC: I read
[18]http://www.w3.org/2001/tag/doc/versioning-html/versioning-html-2
0090611.html looking for Baron's argument and didn't find it

[18]
http://www.w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html

LM: Where are we?
... JR and I wrote a document

NM: One design point -- all features have a permanent and
never-to-be-changed meaning
... at whatever point they are introduced
... In that case, I claim version indicators are redundant
... OTOH, in other cases there may be changes in interpretation
between versions

<masinter> version indicators are only redundant. They may be
useful, but they're not necessary. if you assume web agents are only
browsers and (hand-coded) web pages

<masinter> authoring tools and validators can use version
indicators, for example

NM: In this case version indicators are necessary

<masinter> would like to go through document

<masinter> further, not entirely in control of every aspect

TBL: HTML is generated by people who pull stuff together -- if they
can't get their act together to match start and end tags, they
certainly won't match the whole document to what is essentially the
top of the doc
... NM, your dichotomy is too clean -- in general, evolution isn't
that nice, things change by accident, or to fix bugs in a previous
version
... A single-dimensional VI can almost never achieve accuracy

LM: I'd like to focus on the document, but first
... VIs are only redundant if you look only at hand-authored content
and browsers
... Authoring tools are assisted, and do their job better, if they
have a version target
... They're helpful in content management, as a signal of intended
target
... There's a whole economy of production, consumption, analysis,
etc.

act next

TBL: Not just _people_ scribbling, but pulling stuff from RSS feeds,
DM systems pulling bits from store and script, etc.

<DanC_lap> (DM systems? I think maybe CM systems)

<DanC_lap> (ah... document management)

<masinter> document management vs content management

TBL: so even in cases w/o a single human author have consistency
pblms

<masinter> i've tried to be careful between "version indicator" and
"doctype"; certainly doctype has weaknesses

<Zakim> ht, you wanted to be precise about 'redundant'

HST: I think there is a sense in which what NM said was true,
because tautological, but that doesn't make LM's point invalid

NM: I heard LM say that the VI is advice, or a statement of intent,
not just a summary of an otherwise-determinable fact
... Let's look at
[19]http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090
611.html

[19]
http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html

LM: This isn't scoped to the "Is there a DOCTYPE in HTML5", but it
bears on that question
... It's about what we mean by words like 'language' and 'version'
... Guidelines to groups on how to write extensible languages

<DanC_lap> (editorial comment: in-your-face URIs are ugly; they're
sometimes necessary in constrained environments, but this document
is written in HTML, where you can just use normal links)

LM: A language is an agreement of a community on meaning, wrt
strings (and maybe syntax)
... I'm uttering [a text], and we have an agreement on what it means
... We're dealing with a community in which many different agents
(authors, browsers) have there own precise definition of a language
in those terms
... A standard is then an attempt to coordinate all those languages
into something expressed in a language specification,
... so that all the parties can use the language to communicate

JR: Yes, I think my attempt to confine the definition of 'language'
to appeal only to consumers is probably wrong

NM: I still, going all the way back to our discussions in Edinburgh
[in 2005?], that 'language' has an important nature independent of
producers _and_ consumers

TBL: But it was there that we _introduced_ the dependence on
producers and consumers

NM: We started with the question "per some language specification,
is this text in the language or not?"

LM: We end up distinguishing between a language, which is an
agreement, and a language specification, which is an attempt to
record that agreement

<DanC_lap> (editorial comment: I don't like up-front Terminology
sections. I prefer to see the terms introduced in context. put a
glossary/index at the end if you like0

<DanC_lap> 0

<DanC_lap> )

LM: This allows us to distinguish between "What the spec. says" and
"What was implemented"
... regardless of which comes first -- a spec. can be an
after-the-fact attempt to record an agreement which is instantiated
in implementations, or it can be a proposal which may or may not be
consistently adopted and then implemented

NM: Reasons for language change
... How do languages change? The kind of promises we should make
about the future can be informed by an analysis of what kind of
changes have happened in the past
... Incompatible changes happen, for good reasons
... This section is incomplete

DC: It would be good to remember the players: a lot of authors, even
more readers, few implementors. . .

I would add, per LM, quite a few non-human consumers

[LM continues to summarize the document]

<DanC_lap> note D Baron's essay
[20]http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.htm
l

[20]
http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html

LM: There is this bizarre reciprocal heuristic behaviour -- servers
are trying to detect what they're serving to, browsers are trying to
detect what language they are about to render, and the situation has
gotten recursive, i.e. spoofed user agent strings in order to
provoke particular kinds of content

<DanC_lap> jar, that's the one

LM: User-agent string and request headers are related to VIs

JR: And content negotiation

NM: The UA string indirectly indicates the language the client is
expecting to render
... The server responds not with explicit VIs, but variants that are
intended to be tuned to the 'version' requested

<johnk_> User-agent header is an implementation version indicator

<johnk_> (not a language version indicator)

TBL: Note that if HTML5 at the moment is using DOCTYPE as part of
its heuristic, that's perhaps an indication that version indicators
would be useful in the future as well

<raman> calling zakim

we're just dialing in

We're working through Larry and Jonathan's document:
[21]http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090
611.html

[21]
http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html

<DanC_lap> (construction noise)

JR: Wrt Motivation of Implementors of Agents section, this is about
the Must Understand rule
... RDFa has been called dangerous to put into HTML, because it
can't be checked automatically
... and since it's not meant for human eyes, it can be ignored by
browsers

NM: OK, so not the same as the SOAP mustUnderstand flag

JR: I'm working to the criticism that RDFa violates the 'no
invisible metadata' HTML5 design principle

DC: Not documented as a design principle, but yes

<DanC_lap> (zeroing in on it
[22]http://microformats.org/wiki/invisible-data-considered-harmful )

[22] http://microformats.org/wiki/invisible-data-considered-harmful

NM: The concern is that the user never sees this stuff, so can't be
sensitive to its significance

DC: The worry is, among other things, that invisible data rots, it
isn't maintained because no-one notices if it's stale/wrong

JR: But this is an ecology, there are multiple audiences
... Why isn't this a critique of comments? (which end up being
re-purposed for automatic consumption)

<DanC_lap> (which section did LMM pick just now?)

LM: If this were to become a Finding, we have some recommendations
to add -- there are placeholders in case we decide to do so
... I don't accept the "HTML is unique" argument for ignoring all
background/precedent
... Ignore what you don't understand is not really an option for
imperative languages

HST disagrees -- the "debugging a blank sheet of paper" approach to
LISP programming depends on the fact that a function which names but
does not use at runtime uba or udf is not broken

LM: Moving on to JR's formalism
... Needs to be up-leveled to deal with communities of consumers and
producers

JR: Sure, like statistical thermodynamics -- you have to _start_
with two-particle interaction, and then take it up-level
... ref. is John Maynard Smith (application of game theory to study
of animal behavior)

q

HST thinks there's something odd when the consumers are by
construction _identical_. . . Not sure what impact on modelling this
might have

NM: Adjourned for lunch, back 1315EDT or thereabouts

TV, are you there?

<raman> here

<raman> calling

stand by

<johnk> ScribeNick: johnk

<scribe> Scribe: John Kemp

<raman> on zakim

<raman> all by myself

<ht> noah having trouble keying

Web Application State Management

[23]http://www.w3.org/2001/tag/2009/06/23-agenda#webAppState

[23] http://www.w3.org/2001/tag/2009/06/23-agenda#webAppState

NM: (summarizes morning's discussion)
... we might add a section to AWWW focused on web as application
platform
... which might have implications for this topic ( web app state)

TVR: discussion of changing URL -> URI - where are we?
... what should I edit?

HT: The "URI" version

TVR: (discusses the logistics of the document)

<DanC_lap> technical stuff first, please

TVR: should we tackle logistics or tech details first?

DC: tech first

TVR: we decided to make this public draft, engaging W3C process and
raising related issues

NM: summarizes issue raised about W3C patent process, and suggests
we solve in email

ACTION Noah to ensure any issue is resolved with Art

<trackbot> Created ACTION-277 - Ensure any issue is resolved with
Art [on Noah Mendelsohn - due 2009-06-30].

TVR: move on to technical issues
... we do not yet have "deep" recommendations, simply a list of ways
people are using client-side # URIs

<noah> Noah note to self: Action 277 is to make sure we are
addressing Art's concerns with the basis on which TAG members
participate and disclose patents. To be picked up late July.

<DanC_lap> action-277: Noah note to self: Action 277 is to make sure
we are addressing Art's concerns with the basis on which TAG members
participate and disclose patents. To be picked up late July.

<trackbot> ACTION-277 Ensure any issue is resolved with Art notes
added

TVR: write down the different usages to identify conflicts between
different methods

<masinter> thought on this: update the URI specification to redefine
"fragment" after # to be 'parameters sent to interpreter' rather
than 'fragment'

<masinter> or else redefine 'fragment' for HTML only

TVR: "push state"

<DanC_lap> how is "push state" spelled? I can't find it

TVR: this is in a more recent draft
... than the one in the agenda

<raman>
[24]http://www.whatwg.org/specs/web-apps/current-work/multipage/hist
ory.html#dom-history-pushstate

[24]
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#dom-history-pushstate

TVR: in a browser you have window, which has document which has a
URI
... browser back and forward can page from one URL doucment to the
other
... world more complicated now
... overall state is now more than a URI
... "state" object where window.history contains these state objects

<jar> like form fields?

TVR: so what does this have to do with HashinURL?
... pushState( state, title, url)
... then history list is states with/without URL and vice-versa
... what is your window.location then?
... URL + this state object referenced as a JSON object in the URI
fragment

NM: are we going anywhere with this document?
... we currently say "here is what's happening"
... should we go beyond that?
... and then, do we have comments on pushState?
... so.... work backwards through that list

<DanC_lap> pushState is sort of obviously good as far as
standardizing a pattern that is in lots of JS libs, right?

LMM: not sure I understand the issue
... is it role of fragment ID of indicating state, or about this use
of state?

NM: relates to metadata in URI finding
... one case where this state is private to your browser session

TVR: these URIs do show up in browser address bar

NM: so they can leak out
... one position is that these are private
... how should we tell the story about the relationship between the
server and client in this case?

<raman> GMail is a better example

NM: (gives Google Maps example)

<noah>
[25]http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#forms

[25] http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#forms

NM: address bar doesn't change, but can use 'link' URI to paste to
email etc.
... server sent client a big pile of JS
... metadata finding, server sent client a form
... in both cases, server allows client to mint URIs
... if something comes from resource authority, then we can assume
it knows how to deal with URIs minted by the client
... sees a parallel here
... resource owner assigns meaning to all URIs and has encoded that
knowledge into JS sent to client
... we could make this connection explicit between these two
findings

AM: If I zoomed into the same spot to Google Maps in my browser,
would I see the same thing?

NM: not necessarily, but it is still "server consistent"

TVR: there are secondary requests with secondary arguments encoded
as '#' parameters

NM: isn't that different than what I explained?

TVR: Gmail has notions of thread ID and message ID which can be used
to get back the same message/thread

NM: this is like the Maps case, where these ids can be mailed/pasted

<DanC_lap> "identification is orthogonal to access control" --
bookmark that thought for later ;-)

TVR: there are security implications with passing these state ids
around

NM: this is discussed in the metadata in URIs finding

<Zakim> noah, you wanted to talk about HTML forms and metadata in
URI finding

LMM: the frag id is being used to pass parameters to the UA
... is this a property of the HTML MIME type?
... since HTMLis the authority for that MIME type
... in XHTML case would this delegate to the XML document?

NM: I'm synthesizing an HTML doc from a bunch of different
files/places, and creating a DOM

LMM: fragment identifier is a property of the representation
retrieved of the resource accessed
... should there be an update to what fragment identifiers mean,
such as in HTML case?
... how to do give an identifier to an application in a particular
state?

<DanC_lap> (hmm... does the HTML 5 spec cover this mime
type/fragment stuff? are there plans to? looking it up...)

LMM: how can you construct identifiers which can identify an
application in a particular state?

NM: see this as a set of "virtual documents" - not been in a
monolithic application
... should be a discussion about the set of URIs for the virtual
document

LMM: transition from Web 1 to Web 2 was about transition from
virtual documents linked together to one where application state is
the thing transferred

TBL: agree with both of you

LMM: identifier is not just for a resource, but for a resource state

TBL: people are looking at a place (on a map) - not a state of a map
... that is what is invariant

<DanC_lap> (yes, there seem to plans to...
[26]http://www.w3.org/html/wg/tracker/issues/53 ISSUE-53
mediatypereg Need to update media type registrations State: RAISED)

[26] http://www.w3.org/html/wg/tracker/issues/53

NM: we can agree that both of these views are coherent
... document/resource-oriented view is a good model that bridges
this web 1.0/2.0 gap

LMM: model is less descriptive of what is going on
... when I sent you a URI of Google Maps pointing at Cambridge, I'm
also sending you a link to an application which has the ability to
zoom to that place on a larger map

NM: true, but not so different from resource-oriented view

AM: describe the link to metadata in URI again?

NM: main question is "what right do I have to guess what URIs are
appropriate here?"
... resource owner chooses
... we tell the story of HTML forms
... two cases:- form itself came from resource authority, so you can
assume that URIs delivered are consistent according to the owner
... second is that "all bets are off" otherwise

TVR: what are you suggesting?

NM: point to metadata in URI from Has in URI and draw the parallels

LMM: what problem are we trying to solve here?

DC: people that might be using two conflicting JS libraries
... they mostly don't "bump into each other"

TBL: looking at DCs FOAF page - URI of "you"
... inside tabulator, nowhere to see the #
... RDF has "used" the #
... could propose an "extended URI" scheme
... ##

NM: I'd like to see the Google Maps method explained - showing this
usage of the 'link' allowing me to send/email a URI
... showing people how to do this "on the web"
... is good
... equivalent of using cookies to represent state (URI alone is not
useful)
... navigation in these apps is often done quite privately

LMM: OpenAJAX Alliance works on good practice statements for AJAX
apps
... would our advice fit into their domain, for example?
... is this advice on building web 2.0 applications?

TBL: architectural principal is that user should "have a history"
(to browse)

HT: there are some interesting ways in which web 2.0 "breaks the
Web"
... much less content that you see is being indexed than it was 5
years ago, because content is synthesized depending on things more
than the URI + original representation
... crawlers don't see all the things they need to see (forms,
cookies etc.)
... crawlers get stuck in "tarpit" when they attempt to explore such
spaces

<DanC_lap> (hark to alexa vs the original calculator web site...)

<DanC_lap> (oops; altavista, not alexa)

HT: image we have of webarch is that servers represent hierarchical
file systems

<Zakim> ht, you wanted to remark on non-Browser agents

HT: if this document could bring this issue to the foreground and
draw attention to tradeoffs

LMM: this issue is an important instance of a larger problem
... happy to deal with large problems by dealing with single
instances, but need to be sure we can address the broad issue with
this example

<raman> simple answer to Larry's "why are we doing this" -- because
someone on the TAGis motivated to work on it

NM: there are new idioms for building apps, and I think it's a good
thing to write down these issues and tradeoffs

<raman> we could say that that shouldn't be how the TAGworks, which
is a fine thing to do, but in my experience, people only work on
things that motivate them:-)

NM: do we need another session?

TVR: I don't think so

NM: so, where should we go with this?

TVR: if content doesn't change it should turn into a note

AM: would rather consider this in the context of AWWW for web
applications

LMM: would publish this as a note describing the issue, and noting
it as part of a bigger effort

TVR: happy with the idea of publishing this as a note, and as part
of a larger effort

NM: where to draw the line?

<DanC_lap> (I heard TVR say he's happy provided the larger effort
happens)

TVR: (says a lot of stuff I didn't hear well enough)

NM: what would you do to get more comments?

TVR: not sure
... worried that our work is dropping off the radar

NM: make no decision right now (on what to do next)
... try looking at the web arch for web applications first

LMM: would like to see a more specific proposal

TVR: will do no further work without further input
... what about cases beyond HTML+Javascript?

NM: thinks TVR is talking about how these parameters are used in
things such as Adobe Air

LMM: describes media type registration for PDF and its use of #

TBL: what happened timbl to plaintext # line numbers?

LMM: desire to have "more robust" pointers than line numbers
... for web apps, how you do pointers to app state that survive app
updates is interesting
... HTML frag ids are robust in that way
... as you move to other media, the issue of robustness of such
pointers is important

NM: would like to see links to the metadata in URI finding, but
other than that, put it aside for now
... look at larger issue (web app arch) and revisit
... this issue in that context
... (break)

<timbl>
data:text/plain;Text%20plain%20fragids%20are%20like%20L0%20%28same%2
0as%20L0-L1%29%20or%20L0C0-L3C6%20with%20obvious%20meanings.

Javascript Security

[27]http://www.w3.org/2001/tag/2009/06/23-agenda#security

[27] http://www.w3.org/2001/tag/2009/06/23-agenda#security

JAR: how to relate the various security issues discussed?
... discussion of Origin header and related risks
... Javascript security related to DC
... relationship to web architecture of JS security
... wrote
[28]http://www.w3.org/2001/tag/doc/resource-protection/20090615

[28] http://www.w3.org/2001/tag/doc/resource-protection/20090615

<raman> could you call in to zakim?

JAR: Cross-origin requests fall into confused deputy problem

dialling in

JAR: traditional ACL model doesn't work in situations where there
are more than two parties involved in security
... risks when you separate the credentials from the name
... that is why this is a "forgery" (forging the link between the
name and the credentials)

NM: is this typically a cookie problem?

JAR: whatever ambient credentials held with the site
... could be IP address, client cert or other ambient creds

HT: scenario is by whatever means I am looking at page served by
attacker, with link to legitimate page which when clicked will send
user's creds to the legitimate site

(discussion about examples of this issue)

JAR: reiterates the three items at the beginning of this topic
... defense against confused deputy attack is to keep creds closely
linked to the name

jk: one way is to make the creds and name the same

JAR: can use nonce for example (provide unguessable name)
... secure ECMAscript packages credentials into the object
... you can then put potentially hostile code into a container
... link to web arch is regarding naming
... Tyler (Close)'s solution is to put the creds in the URI
... in JS you'd pass that URI around as part of a JS object

AM: if you have an object with these things in it, there are no
methods to extract the credentials?

JAR: if creds are hashed together with the URI, then even if
attacker can get access, it cannot change the link between the name
and the creds

NM: so URI can be more than a name?
... if you're encouraging people to use URIs which cant be
bookmarked, that's not good for webarch

<Zakim> DanC_lap, you wanted to share some thoughts on
[29]http://waterken.sourceforge.net/web-key/

[29] http://waterken.sourceforge.net/web-key/

DC: saw Tyler's papers, and have met him
... lots of discussion that acl is orthogonal to naming

TBL: we talk about the difference between authn and authz

<raman> off to lunch in 4 mins.

<raman> back in 45 mins or so

<DanC_lap> DC: I think there's room to acknowledge capability style
URIs as well as URIs that you can mail around without giving access

<DanC_lap> Tyler's "Mashing with permission"
[30]http://waterken.sourceforge.net/web-key/ is an extensive
critique of 3.5.2. Linking and access control
[31]http://www.w3.org/TR/webarch/#id-access

[30] http://waterken.sourceforge.net/web-key/
[31] http://www.w3.org/TR/webarch/#id-access

<Zakim> johnk_, you wanted to talk about multiple identities

JK: which credentials are carried in these references?

<Zakim> noah, you wanted to ask about URIS as capabilities

JAR: you could encode multiple sets into a reference

DC: there is a style where URI is a capability
... Tyler's analysis is that leaking of URIs is less of a problem
than phishing+cross-site request forgery

NM: so, advice in 2.7 of Metadata in URIs is still good advice?

JAR/DC: no, Tyler et al say this is bad advice!

LMM: advice is good for some situations, bad for others

TBL: appropriate to say that there are two patterns of use - 1) ACL
is done orthogonally to URI metadata (metadata MAY be public)
... and another, where URI must be completely secret

HT: you are fooling yourself if you think URIs won't get out into
the wild

(missed TBL third case) - secret information in URI, as noted in 2.7
of metadata in URI spec.

TBL: (describes tripIt 'send to' case)

NM: there is a story about if I use HTTP, then URIs will appear in
several places
... and with HTTPS, fewer places

TBL: re-open the metadata in URLs finding, explain capability
use-case

[32]http://www.w3.org/TR/access-control/ Cross-origin Resource
Sharing

[32] http://www.w3.org/TR/access-control/

JAR: there is conflict between CORS and this capability approach
... Tyler and Mark Miller asking for GuestXHR feature support in
CORS
... to have a way to issue a request such that request is stripped
of all credentials

NM: Guest approach only useful with Caja-like approach?

JAR: you could also build your own sandbox

NM: don't think the metadata in URI finding should deal with all the
work on this issue

JAR: mnot sent email regarding an issue with CORS -
[33]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/06
43.html
... concern that this WD is a threat to the use of URIs - causing
people to switch from REST mode to SOAP-like methodology

[33]
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0643.html

LMM: Origin header has been deployed

JAR: Comments are i) CORS has impact on Web Arch (see above line
about REST/SOAP) ii) ACLs won't solve all the issues
... if you accept the capabilities approach, then CORS seems
antithetical

LMM: process issue is that orgs which build security infrastructure
for the Internet should review this document (CORS)
... responsibility of WGs to get this review

NM: we could comment on this draft

HT: TAG exists because of need to provide web-arch related comments
early enough in WG spec. process
... there is precedent for director to hold some specs. to a higher
bar when exiting CR
... so, we have an obligation to say something to the WG - that is
the role of the TAG

NM: is it about what we (TAG) think, or lack of implementations by
particular groups (such as server vendors)?

LMM: the Origin header didn't seem to have significant support from
server vendors
... risk when deploying something insufficient for solving the
problem, is that it becomes a distraction from solving the actual
problem
... particularly a problem for security-related issues

NM: not sure about the concrete steps

AM: we've said that URIs are public and can be sent around, and now
we're saying... maybe not

DC: we should send a comment to CORS regarding CR exit criteria

LMM: I believe the counter-arguments against the CORS approach are
credible and reasonable
... but would prefer we get the involvement of security experts in
order to resolve the conflict
... and would require the involvement of server vendors

NM: strawman - we write a note saying we have reviewed these specs,
and have been made aware of possible shortcomings
... we feel these concerns should be convincingly addressed

<ht> The current state of play:
[34]http://news.netcraft.com/archives/web_server_survey.html

[34] http://news.netcraft.com/archives/web_server_survey.html

NM: TAG may do more research, but would prefer the WG confer with
security experts, but also note that acceptance by server vendors
might resolve these concerns

Action to ht to draft a message to webapps chairs relaying TAG
concerns around CORS

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

<scribe> ACTION: ht to draft a message to webapps chairs relaying
TAG concerns around CORS [recorded in
[35]http://www.w3.org/2009/06/23-tagmem-minutes.html#action01]

[35] http://www.w3.org/2009/06/23-tagmem-minutes.html#action01

<scribe> ACTION: Henry to draft a message to webapps chairs relaying
TAG concerns around CORS [recorded in
[36]http://www.w3.org/2009/06/23-tagmem-minutes.html#action02]

[36] http://www.w3.org/2009/06/23-tagmem-minutes.html#action02

<DanC_lap> trackbot, status

<scribe> ACTION: Jonathan to draft changes to 2.7 of Metadata in
URIs to cover the "Google Calendar" case [recorded in
[37]http://www.w3.org/2009/06/23-tagmem-minutes.html#action03]

[37] http://www.w3.org/2009/06/23-tagmem-minutes.html#action03

<trackbot> Created ACTION-278 - Draft changes to 2.7 of Metadata in
URIs to cover the "Google Calendar" case [on Jonathan Rees - due
2009-06-30].

<scribe> ACTION: Henry to draft a message to webapps chairs relaying
TAG concerns around CORS [recorded in
[38]http://www.w3.org/2009/06/23-tagmem-minutes.html#action04]

[38] http://www.w3.org/2009/06/23-tagmem-minutes.html#action04

<trackbot> Created ACTION-279 - Draft a message to webapps chairs
relaying TAG concerns around CORS [on Henry S. Thompson - due
2009-06-30].

<DanC_lap> action-278 due 7 july

<trackbot> ACTION-278 Draft changes to 2.7 of Metadata in URIs to
cover the "Google Calendar" case due date now 7 july

<noah>
[39]http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037
.html

[39]
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037.html

<noah> Raman, I'm not sure if you're lurking, but shortly we will be
discussing scheduling of future meetings, etc.

<raman> calling zakim

JAR: notes Roy's email on this subject
[40]http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037
.html

[40]
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037.html

<jar> You can have CSRF even with completely static content.

<noah> Warning, just as we were about to wrap, Dan asked to talk
about more security, and I agreed.

DC: (draws 2x2 table) with CSRF cases for GET and POST

1. attacker hosts JS, which is executed by consumer which sends a
GET to bank

2. is 1. with POST, and JS

second column has no javascript

3. (no JS, GET) attacker is malicious, bank is negligent (executes a
GET with side-effects - img tag calls the GET and hides the
side-effect without user input)

4. POST with no JS, and user is asked to click something to same
effect as 3.

DC: without negligent system entities, are there still attacks of
these forms?

TBL: A POST is a commitment by a user, and should be presented as
such

I think we should document the examples in this table, and possibly
derive advice to users and servers which wish to mitigate such
attacks

<DanC_lap> s/without negligent system entities/without allowing GET
scripts to POST/

<DanC_lap> close ACTION-274

<trackbot> ACTION-274 See if I can reconstruct a discussion with tlr
where present course and speed will lead to GET-based links becoming
regarded as unsafe closed

NM: propose we document this table, first as an email

<DanC_lap> ACTION: DanC (with John K) to enumerate some CSRF
scenarios discussed in Jun in Cambridge [recorded in
[41]http://www.w3.org/2009/06/23-tagmem-minutes.html#action05]

[41] http://www.w3.org/2009/06/23-tagmem-minutes.html#action05

<trackbot> Created ACTION-280 - (with John K) to enumerate some CSRF
scenarios discussed in Jun in Cambridge [on Dan Connolly - due
2009-06-30].

JAR: what about my note on resource protection?

<DanC_lap> +1 TAG blog. good to acknowledge the criticism of
"addressing is orthogonal to access control" pattern

<DanC_lap> (capture a sound-bite from noah: "how GET becomes
unsafe")

(discussion about blog post vs notes/findings)

LMM: first inclination is to blog it in TAG blog

NM: ADJOURN

Summary of Action Items

[NEW] ACTION: DanC (with John K) to enumerate some CSRF scenarios
discussed in Jun in Cambridge [recorded in
[42]http://www.w3.org/2009/06/23-tagmem-minutes.html#action05]
[NEW] ACTION: Henry to draft a message to webapps chairs relaying
TAG concerns around CORS [recorded in
[43]http://www.w3.org/2009/06/23-tagmem-minutes.html#action02]
[NEW] ACTION: Henry to draft a message to webapps chairs relaying
TAG concerns around CORS [recorded in
[44]http://www.w3.org/2009/06/23-tagmem-minutes.html#action04]
[NEW] ACTION: ht to draft a message to webapps chairs relaying TAG
concerns around CORS [recorded in
[45]http://www.w3.org/2009/06/23-tagmem-minutes.html#action01]
[NEW] ACTION: Jonathan to draft changes to 2.7 of Metadata in URIs
to cover the "Google Calendar" case [recorded in
[46]http://www.w3.org/2009/06/23-tagmem-minutes.html#action03]

[42] http://www.w3.org/2009/06/23-tagmem-minutes.html#action05
[43] http://www.w3.org/2009/06/23-tagmem-minutes.html#action02
[44] http://www.w3.org/2009/06/23-tagmem-minutes.html#action04
[45] http://www.w3.org/2009/06/23-tagmem-minutes.html#action01
[46] http://www.w3.org/2009/06/23-tagmem-minutes.html#action03

[End of minutes]
_________________________________________________________

Minutes formatted by David Booth's [47]scribe.perl version 1.135
([48]CVS log)
$Date: 2009/07/21 19:39:15 $

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

Approved minutes of June 2009 TAG Face to Face meeting

2009-08-10T13:44:04Z

During its teleconference of 23 July 2009, the TAG voted to approve [1]
the minutes of our F2F meeting of 23-25 June 2009. As has been our
recent custom, the minutes are cross referenced from an updated copy of
the meeting agenda, which is available at [2], and in text form below.

The actual minutes are in three separate Web documents [3-5]. For the
convenience of those who require text for use with assistive technologies,
and as an aid to finding them in the TAG's email archives, text-only
versions of these will be sent in separate emails momentarily. Note that,
for most users, the links in [2] will be the most effective way to find
things.

Noah

[1] http://www.w3.org/2001/tag/2009/07/23-minutes#item02
[2] http://www.w3.org/2001/tag/2009/06/23-agenda
[3] http://www.w3.org/2001/tag/2009/06/23-minutes
[4] http://www.w3.org/2001/tag/2009/06/24-minutes
[5] http://www.w3.org/2001/tag/2009/06/25-minutes

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

[1]W3C | [2]TAG | Previous teleconference: [3]11 June 2009 | Next
teleconference: 16th July 2009 (tentative).

[1] http://www.w3.org/
[2] http://www.w3.org/2001/tag/
[3] http://www.w3.org/2001/tag/2009/06/11-minutes

TAG face-to-face meeting, 23-25 June 2009 — MIT Stata Center,
Cambridge, MA, USA

[4]Picture of the TAG

[4] http://www.w3.org/2001/tag/2009/06/TagStataPictureHiRes.jpg

Noah Mendelsohn, Jonathan Rees, Tim Berners-Lee, Dan Connolly, Henry
Thompson, Larry Masinter, Ashok Malhotra, John Kemp

Nearby: [5]issues list - [6]findings - [7]www-tag archive - [8]tag
archive - Actions: ([9]open, [10]pending review)

[5] http://www.w3.org/2001/tag/group/track/issues
[6] http://www.w3.org/2001/tag/findings
[7] http://lists.w3.org/Archives/Public/www-tag/
[8] http://lists.w3.org/Archives/Member/tag/
[9] http://www.w3.org/2001/tag/group/track/actions/open
[10] http://www.w3.org/2001/tag/group/track/actions/pendingreview

Regrets: T.V. Raman will be participating by phone from the West
Coast, and will be available only for afternoon sessions.

Agenda Summary

Tues 23rd June
Agenda Minutes
08:00-9:00 Arrive & Set up
The meeting room will be available. Please have your computers and
network connections set up for a prompt start at 9AM.
1. [11]Convene & Administration
2. [12]W3C Work on APIs
3. [13]Language Versioning and HTML
4. [14]Web Application State Management
5. [15]Javascript Security

[11] http://www.w3.org/2001/tag/2009/06/23-minutes.html#item01
[12] http://www.w3.org/2001/tag/2009/06/23-minutes.html#item02
[13] http://www.w3.org/2001/tag/2009/06/23-minutes.html#item03
[14] http://www.w3.org/2001/tag/2009/06/23-minutes.html#item04
[15] http://www.w3.org/2001/tag/2009/06/23-minutes.html#item05

09:00-9:15 [16]Convene
Appoint Scribes, Review F2F Logistics, etc
09:15-9:30 [17]Review F2F Goals and Agenda
9:30-10:30 [18]W3C work on Web APIs
10:30-10:45 Break (15 mins)
10:45-12:00 [19]Language Versioning and HTML (session 1 of 2)
12:00-13:15 Lunch - with W3C & DIG staff (W3C open area - 5th Floor
Gates Tower - 75 mins)
13:15-14:45 [20]Web Application State Management (session 1 of 2)
14:45-15:00 Break (15 mins)
15:00-16:30 [21]JavaScript Security
16:30-17:00 [22]TAG Administration: future meetings, etc.
Weds 24th June
Agenda Minutes
09:00-10:15 [23]The Mobile Web
1. [24]Mobile Web
2. [25]Metadata Access and Formats
3. [26]Versioning and HTML
4. [27]Web Arch for Applications
5. [28]tag administration issues

[24] http://www.w3.org/2001/tag/2009/06/24-minutes.html#item01
[25] http://www.w3.org/2001/tag/2009/06/24-minutes.html#item02
[26] http://www.w3.org/2001/tag/2009/06/24-minutes.html#item03
[27] http://www.w3.org/2001/tag/2009/06/24-minutes.html#item04
[28] http://www.w3.org/2001/tag/2009/06/24-minutes.html#item05

10:15-10:45 Break (30 mins)
10:45-12:00 [29]Metadata access and formats
12:00-13:15 Lunch (75 mins)
13:15-14:00 [30]Language Versioning and HTML (session 2 of 2)
14:00-15:15 [31]Web Architecture for Applications
15:15-15:45 Break & picture? (30 mins)
16:15-17:00 [32]TAG Administration: future meetings, etc.
Thurs 25th June
Agenda Minutes
09:00-10:30 [33]Naming Schemes
1. [34]Naming Schemes
2. [35]HTTP Semantics
3. [36]TAG f2f scheduling
4. [37]Tag priorities and future work
5. [38]Architecture for Web Applications
6. [39]HTML 5 review

[34] http://www.w3.org/2001/tag/2009/06/25-minutes.html#item01
[35] http://www.w3.org/2001/tag/2009/06/25-minutes.html#item02
[36] http://www.w3.org/2001/tag/2009/06/25-minutes.html#item03
[37] http://www.w3.org/2001/tag/2009/06/25-minutes.html#item04
[38] http://www.w3.org/2001/tag/2009/06/25-minutes.html#item05
[39] http://www.w3.org/2001/tag/2009/06/25-minutes.html#item06

10:30-10:45 Break (15 mins)
10:45-12:00 [40]HTTP Semantics
12:00-13:30 Lunch (90 mins)
13:30-15:00 [41]TAG Priorities
16:00-17:00 ...those who are not traveling may wish to stay for
informal discussion...
Unscheduled topics
There are some other topics we may decide to discuss in the free
time slots. Suggested discussion goals and preparation materials are
available in the section linked below.
[42]Unscheduled topics

Note that preparation is also encouraged for some items for which
[43]fixed time slots have not been allocated. We may or may not
decide to discuss some or all of these, presumably in the sessions
not yet scheduled.

Logistics

(there is also a separate [44]logistics page)

[44]
http://www.w3.org/2001/tag/2009/06/06-f2f-local-arrangements.html

Venue
MIT, Stata Center
32 Vassar Street
Cambidge, MA 02139

Schedule:
Tue 23 June: 09:00 - 17:00
Wed 24 June: 09:00 - 17:00
Thurs 25 June: 09:00 - 16:00

Agenda Details

1. Convene
Goals:
+ Appoint scribes
+ Review F2F logistics
+ Approve minutes of telconferences
o [45]11 June 2008
2. Review F2F Goals and Agenda
Session shepherd:
Noah Mendelsohn
Session goals:
+ Review F2F Goals
o Establish more clearly TAG priorities for coming year
o Set goals and decide next steps for [46]ISSUE-60
(WebApplicationState-60) and for working draft
[47]Usage Patterns For Client-Side URI parameters
o Decide whether further TAG work on extensibility and
versioning will be cost effective, and in particular
whether it will likely have positive impact on the
development of HTML 5.
o Decide whether the TAG should be working more actively
in areas relating to use of the Web with "mobile"
devices.
o Decide whether the TAG should begin consideration of
architectural issues relating to W3C standardization
of APIs used for Web Application development.
o Make progress on other open TAG issues (e.g. metadata,
use of URI schemes, security, etc.)
+ Review F2F Agenda ([48]this document)
Preparation:
+ [49]Whiteboard summary of proposed TAG priorities from
March 2009 TAG F2F.
+ [50]TAG F2F Priorities email from Noah
3. W3C Work on Web APIs
Session shepherds:
Ashok Malhotra, John Kemp
Background:
Traditionally, most of the W3C's Recommendations have focused on
data formats such as HTML, identification mechanisms such as
URI's, etc. With the rise of AJAX, JavaScript and similar APIs
have become an increasingly important aspect of content and
application development for the Web, and W3C is considering at
least one [51]proposal to charter work on the standardization of
such APIs.
The TAG has also had some informal discussionts (see thread
starting with [52]email from Thomas Roessler) of Geolocation
APIs and the Geopriv work.
Session goals:
+ Discuss technical and architectural issues relating to Web
APIs.
+ Decide:
o Whether there are technical issues relating to APIs
that merit ongoing consideration by the TAG
o Decide whether the TAG should play a role in helping
the W3C to decide whether to undertake work in this
area, and/or how to structure charters for such work
o Consider privacy and security issues relating to
Javascript APIs that give access to the user's
location.
Preparation:
+ [53]W3C and APIs from Larry Masinter and Ashok Malhotra
([54]announcement email)
+ Email [55]geolocation update from Thomas Roessler.
+ (optional - late addition) [56]Proposed HTML 5 2D graphics
context for use with the [57]canvas element
4. Language Versioning and HTML
Session shepherds:
Jonathan Rees, Larry Masinter
Background:
The TAG has for years studied the means used to evolve document
and programming languages, and techniques for maximizing
interoperability as languages evolve. We have also considered
the structure and evolution of HTML in particular, including the
tradeoffs between "tag soup" and XHTML views of robustness and
error handling. This session is scheduled because some TAG
members have recently proposed that we may be able to apply our
analyses of language versioning to HTML in particular.
TAG Issues relating to this discussion:
+ [58]ISSUE-20 (errorHandling-20) What should specifications
say about error handling? — shepherd: Henry Thompson
+ [59]ISSUE-33 (mixedUIXMLNamespace-33) Composability for
user interface-oriented XML namespaces — no shepherd
+ [60]ISSUE-41 (LanguageVersioning-41) What are good
practices for designing extensible languages and for
handling versioning? — shepherd: Larry Masinter
+ [61]ISSUE-54 (TagSoupIntegration-54) Tag soup integration
— shepherd: Henry Thompson
Session goals (both sessions):
+ Decide whether further work on versioning by the TAG is
likely to have a constructive effect on HTML in particular
+ Consider, as a framework, the [62]draft prepared by Larry
Masinter and Jonathan Rees
+ Decide which issue(s) we will use to track this work, and
ensure that shepherds have been identified.
Preparation:
+ [63]Architectural Considerations for Language Versioning
for the Web (Note from Larry Masinter and Jonathan Rees)
5. [64]ISSUE-60: Web Application State Management
Session shepherd:
T.V. Raman
Background:
+ The TAG has recently issued a First Public Working Draft
titled [65]Usage Patterns For Client-Side URI parameters
Session goals:
+ Make plans for further work on Client Side URI parameters
+ Plan next draft of [66]Usage Patterns For Client-Side URI
parameters
Preparation:
+ First Public Working Draft of [67]Usage Patterns For
Client-Side URI parameters
6. JavaScript Security
Session shepherd:
Jonathan Rees
Background:
+ The TAG recently [68]discussed JavaScript technologies such
as [69]Caja, which apply capability-based sandboxing
techniques to JavaScript. The goal is to support the "safe"
execution of untrusted JavaScript code in a Web page.
+ The chair does not believe that we currently have an open
issue that would provide for continued work in this area.
+ [70]ACTION-274: See if I can reconstruct a discussion with
tlr where present course and speed will lead to GET-based
links becoming regarded as unsafe - on Dan Connolly. This
is marked PENDING REVIEW, and it appears that no followup
on unsafe GET is planned.
Session goals:
+ Clarify significant use cases for safe execution of
untrusted code in Web pages (I.e. remind ourselves why we
care).
+ Further educate the TAG regarding technical work and
standardization efforts relating to safe execution of
untrusted code in Web pages.
+ Decide whether the TAG has a continued interest in working
in this area, and if so, with what goals.
+ Open an issue and assign a shepherd, if appropriate.
Preparation:
+ [71]Resource protection (Jonathan's F2F preparation notes)
+ Paragraph on "Chattiness" in [72]Mark Nottingham's review
of CORS
+ [73]Origin isn't (Tyler Close blog post)
+ [74]Re: The HTTP Origin Header (draft-abarth-origin) (Roy
Fielding email)
+ (optional, longish) [75]ACLs don't (paper by Tyler Close)
+ (optional, long) [76]Cross-origin resource sharing W3C
working draft
7. Mobile Web
Session shepherd:
John Kemp
Background:
+ John Kemp has offered to give us an overview of important
issue relating to the Mobile Web, based on his 10 years of
experience working in that area.
Goals:
+ Get better informed about the Mobile Web, related
architectural challenges
+ Decide whether the TAG wants to undertake work relating
specifically to the Mobile Web. If so, open issues, assign
shepherds, and agree on next steps as appropriate.
Preparation:
+ [77]Mobile Phones, the good, the bad and the ugly
8. Metadata Access and Formats
Session shepherds:
Ashok Malhotra (metadata access), Jonathan Rees (metadata
formats and ontologies)
TAG Issues relating to this discussion:
+ [78]ISSUE-57 (HttpRedirections-57) The use of HTTP
Redirection — shepherd: Jonathan Rees
+ [79]ISSUE-62 (UniformAccessToMetadata-62) — shepherd: Ashok
Malhotra (this issue was "split" from issue-57 at the
[80]March 2009 TAG F2F meeting.)
+ [81]ISSUE-63 (MetadataFramework-63) Metadata on the web:
representations and ontologies? — shepherd: Larry Masinter
([82]ACTION-254 calls for Larry to announce creation of
this issue on www-tag.)
+ [83]ISSUE-54 (TagSoupIntegration-54) Tag soup integration
— shepherd: Henry Thompson
Background:
+ As noted above, we discussed metadata access and formats at
the [84]March 2009 TAG F2F meeting, and we now have 3
issues open, but it's not clear that we are making good
progress.
+ Some TAG members have informed the chair that this area is
of interest to them.
Goals:
+ Take stock of where we are on all of the above, and see
what if anything we actually want to do.
Preparation (Metadata access):
+ [85]Jonathan Rees e-mail discussing LRDD
It has been [86]suggested (member-only) that the TAG review but
not not necessarily take any action on the following drafts:
+ [87]http://tools.ietf.org/html/draft-hammer-discovery-03
+ [88]http://tools.ietf.org/html/draft-nottingham-site-meta-0
1
+ [89]http://tools.ietf.org/html/draft-nottingham-http-link-h
eader-05
Preparation (Metadata formats):
+ [90]Email from Ashok (member only) outlining perceived
interests and concerns of various TAG members. [91]Response
from Raman. (The chair suggests that copies of this
correspondence be moved to the TAG's public www-tag@...
archive.)
9. Naming Schemes
Session shepherd:
Henry Thompson
TAG Issues relating to this discussion:
+ [92]ISSUE-50 (URNsAndRegistries-50): URIs, URNs, "location
independent" naming systems and associated registries for
naming on the Web - shepherd: Henry Thompson
+ May also be related to [93]ISSUE-49 (schemeProtocols-49):
Relationship of URI schemes to protocols and operations -
no shepherd assigned
Goals:
+ Make sure we are agreed on target audience, success
criteria, etc. for this work.
+ Review the new Dirk and Nadia draft
+ Consider whether this work should be better coordinated
with, e.g., [94]ISSUE-49.
+ Decide on next steps.
Preparation:
+ June 2009 draft of [95]Dirk and Nadia design a naming
scheme (the new draft is promised within the next few days
— this agenda will be updated with a pointer to the new
copy when available)
+ [96]John Kemp email (member-only) pointing to [97]Widget
URIs Editor's Draft
+ (optional) [98]Widgets 1.0: URI Scheme W3C First Public
Working Draft 18 June 2009
10. HTTP Semantics (AWWSW)
Session shepherd:
Jonathan Rees
Background:
+ Jonathan Rees has been participating in the regular
teleconferences of a group attempting to more formally
relate HTTP to RDF ([99]email archives). This work was
started, at least informally, under the auspices of the
TAG.
+ Recently, discussions have focused on (a) clarifying and
relating conflicting notions of "information resource" and
(b) considering what HTTP interactions say about resources
independent of httpRange-14. Some questions have arisen,
and the TAG's input may be helpful in resolving them.
Goals:
+ Send agreed TAG comments on [100]the HTTPbis section on 303
responses (see [101]email from Henry suggesting we do
this).
+ Hear a [102]summary from Jonathan of progress that's been
made, and questions that have arisen.
+ Provide guidance on use cases and goals of an HTTP
ontology.
+ Review the nature of the TAG's relationship to AWWSW, and
adjust it if needed.
+ Review [103]Jonathan's review of HTTPbis's treatment of
GET+303.
+ Determine next steps for [104]ISSUE-57.
Preparation:
+ [105]AWWSW status report
+ [106]Summary of current state of HttpRedirections-57
+ [107]Comments on proposed GET+303 text in HTTPbis
11. TAG Priorities
Session shepherd:
Noah Mendelsohn
Background:
+ Discussion of TAG priorities at the [108]March 2009 TAG F2F
(see minutes of all days, as there were several sessions,
and also several lists of potential work areas.)
+ [109]Summary of potential priority work areas gathered on
flip charts at the end of the March F2F
+ Emails from the chair:
o [110]summary of materials relating to TAG priorities
o [111]request that the next round of discussions of
goals and priorities be done using email
([112]response from Tim).
12. Web Architecture for Applications
Background:
At the F2F session on June 23, 2009, the TAG decided to consider
the possibility of a significant enhancement to the Web
Architecture document, to focus on the Web as an application
platform. This might be in the form of revisions to the existing
Web arch document and/or become a second volume.
A rough outline of a table of contents has been written on a
white board:
+ Declarative vs. procedural
+ APIs
+ Modules and dependencies
+ Security - trust boundaries
+ Privacy (including cross-site issues)
+ Client-side URIs
13. TAG Administration
Goals:
+ Discuss summer telconference schedule
+ Discuss dates for future F2F meetings
+ Consider TAG plans for particiation in the [113]November
W3C Technical Plenary and AC Meeting (TPAC)
+ Discuss summer teleconference scheduling
Background:
+ [114]Tabulation of TAG member responses on summer
availability (member-only).
14. Unscheduled items
No specific discussion time is allocated to the following, but
we may choose to discuss these in some of the free time slots.
+ ACTION-265 Work with Larry, Henry to frame technical issues
relating to the vairous overlapping specs. about URIs, IRIs
and encoding on the wire - on Dan Connolly - Due 19 June
2009
+ ACTION-264 Draft agenda item for upcoming telcon discussion
of geolocation and privacy - on Ashok Malhotra - Due 3 June
2009
+ Sniffing - see actions 257 (Noah) & 264 (Larry)

[45] http://www.w3.org/2001/tag/2009/06/11-tagmem-minutes.html
[46] http://www.w3.org/2001/tag/group/track/issues/60
[47] http://www.w3.org/TR/2009/WD-hash-in-uri-20090415/
[48] http://www.w3.org/2001/tag/2009/06/
[49] http://www.w3.org/2001/tag/2009/03/05-whiteboard-priorities.txt
[50] http://lists.w3.org/Archives/Member/tag/2009May/0081.html
[51]
http://lists.w3.org/Archives/Public/public-new-work/2009May/0000.html
[52] http://lists.w3.org/Archives/Public/www-tag/2009Jun/0053.html
[53]
http://lists.w3.org/Archives/Public/www-tag/2009Jun/att-0085/W3C_and_APIs.htm
[54] http://lists.w3.org/Archives/Public/www-tag/2009Jun/0085.html
[55] http://lists.w3.org/Archives/Public/www-tag/2009Jun/0053.html
[56] http://dev.w3.org/html5/spec/Overview.html#the-2d-context
[57] http://dev.w3.org/html5/spec/Overview.html#the-canvas-element
[58] http://www.w3.org/2001/tag/group/track/issues/20
[59] http://www.w3.org/2001/tag/group/track/issues/33
[60] http://www.w3.org/2001/tag/group/track/issues/20
[61] http://www.w3.org/2001/tag/group/track/issues/20
[62]
http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html
[63]
http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html
[64] http://www.w3.org/2001/tag/group/track/issues/60
[65] http://www.w3.org/TR/2009/WD-hash-in-uri-20090415/
[66] http://www.w3.org/TR/hash-in-uri/
[67] http://www.w3.org/TR/2009/WD-hash-in-uri-20090415/
[68] http://www.w3.org/2001/tag/2009/05/28-minutes.html#item06
[69] http://code.google.com/p/google-caja/
[70] http://www.w3.org/2001/tag/group/track/actions/274
[71] http://www.w3.org/2001/tag/doc/resource-protection/20090615
[72]
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0643.html
[73] http://waterken.sourceforge.net/recent.html#id12
[74]
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037.html
[75] http://waterken.sourceforge.net/aclsdont/current.pdf
[76] http://www.w3.org/TR/2009/WD-cors-20090317/
[77] http://www.w3.org/2001/tag/doc/mobile-web-2009-06-18.html
[78] http://www.w3.org/2001/tag/group/track/issues/57
[79] http://www.w3.org/2001/tag/group/track/issues/62
[80] http://www.w3.org/2001/tag/2009/06/23-agenda.html
[81] http://www.w3.org/2001/tag/group/track/issues/20
[82] http://www.w3.org/2001/tag/group/track/actions/254
[83] http://www.w3.org/2001/tag/group/track/issues/20
[84] http://www.w3.org/2001/tag/2009/06/23-agenda.html
[85] http://lists.w3.org/Archives/Public/www-tag/2009Jun/0060.html
[86] http://www.w3.org/2001/tag/2009/06/23-agenda.html
[87] http://tools.ietf.org/html/draft-hammer-discovery-03
[88] http://tools.ietf.org/html/draft-nottingham-site-meta-01
[89] http://tools.ietf.org/html/draft-nottingham-http-link-header-05
[90] http://lists.w3.org/Archives/Member/tag/2009Jun/0043.html
[91] http://lists.w3.org/Archives/Member/tag/2009Jun/0044.html
[92] http://www.w3.org/2001/tag/group/track/issues/50
[93] http://www.w3.org/2001/tag/group/track/issues/49
[94] http://www.w3.org/2001/tag/group/track/issues/49
[95] http://www.w3.org/2001/tag/doc/namingSchemes.html
[96] http://lists.w3.org/Archives/Member/tag/2009Jun/0030.html
[97] http://dev.w3.org/2006/waf/widgets-uri/
[98] http://www.w3.org/TR/2009/WD-widgets-uri-20090618/
[99] http://lists.w3.org/Archives/Public/public-awwsw/
[100]
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-06#page-24
[101] http://lists.w3.org/Archives/Member/tag/2009Jun/0035.html
[102]
http://lists.w3.org/Archives/Public/public-awwsw/2009Jun/0064.html
[103] http://lists.w3.org/Archives/Public/www-tag/2009Jun/0056.html
[104] http://www.w3.org/2001/tag/group/track/issues/57
[105]
http://lists.w3.org/Archives/Public/public-awwsw/2009Jun/0064.html
[106] http://lists.w3.org/Archives/Public/www-tag/2009Jun/0057.html
[107] http://lists.w3.org/Archives/Public/www-tag/2009Jun/0056.html
[108] http://www.w3.org/2001/tag/2009/03/03-agenda.html
[109] http://www.w3.org/2001/tag/2009/03/05-whiteboard-priorities.txt
[110] http://lists.w3.org/Archives/Public/www-tag/2009Mar/0138.html
[111] http://lists.w3.org/Archives/Public/www-tag/2009Mar/0139.html
[112] http://lists.w3.org/Archives/Public/www-tag/2009Apr/0029.html
[113] http://www.w3.org/2009/11/TPAC/overview.html
[114] http://www.w3.org/2001/tag/2009/06/summersched.html

Noah Mendelsohn for TAG
$Revision: 1.42 $ of $Date: 2009/07/31 02:12:01 $

[115]Valid XHTML 1.0 Transitional [116]Valid CSS!

[115] http://validator.w3.org/check?uri=referer
[116] http://jigsaw.w3.org/css-validator/check/referer

TAG First Public Working Draft: Usage Patterns For Client-Side URI parameters

2009-04-16T13:26:32Z

The TAG is pleased to announce the publication of a first public working
draft titled "Usage Patterns For Client-Side URI parameters" [1,2]. From
the Absract:

=======
[...] As highly interactive applications get built using Web parts (HTML,
CSS and JavaScript component resources that are themselves Web addressible
— see [tvr-cacm2009], there is an increasing need for encoding interaction
state as part of the URI. The Web is beginning to discover and codify
design patterns based on fragment identifiers for many of these use cases.

This draft finding is being prepared in response to TAG ISSUE-60 . This
document explores the issues that arise in this context, and attempts to
define best practices that help:

* Create URIs for intermediate pages in a Web application so that
the back button does the right thing
* Enable clients to address into specific points in a stream of
content, e.g., video.

The goal of this finding is to initially collect the various usage
scenarios that are leading to innovative uses of client-side URI
parameters, along with the solutions that have been developed by the Web
community. When this exercise is complete, this finding will conclude by
ensuring that these design patterns are mutually compatible. If some of
these usage patterns are identified as being in conflict, we will
recommend best practices that help side-step such conflicts. We encourage
the wider Web community to point us at emerging usage scenarios and design
patterns so that we maximize our chances of arriving at a final finding
that helps move forward the architecture of the Web in a self-consistent
manner.
=======

The TAG welcomes comments, which should be sent to www-tag@.... Thank
you.

Noah

[1] http://www.w3.org/TR/hash-in-uri/
[2] http://www.w3.org/TR/2009/WD-hash-in-uri-20090415/

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

W3C TAG Finding "The Self-Describing Web" has been published

2009-02-08T09:27:31Z

I am pleased to announce that the W3C TAG has published a new Finding titled "The Self-Describing Web" [1].

Abstract

The Web is designed to support flexible exploration of information by human users and by automated agents. For such exploration to be productive, information published by many different sources and for a variety of purposes must be comprehensible to a wide range of Web client software, and to users of that software.

HTTP and other Web technologies can be used to deploy resource representations that are self-describing: information about the encodings used for each representation is provided explicitly within the representation. Starting with a URI, there is a standard algorithm that a user agent can apply to retrieve and interpret such representations. Furthermore, representations can be what we refer to as grounded in the Web, by ensuring that specifications required to interpret them are determined unambiguously based on the URI, and that explicit references connect the pertinent specifications to each other. Web-grounding ensures that the specifications needed to interpret information on the Web can be identified unambiguously. When such self-describing, Web-grounded resources are linked together, the Web as a whole can support reliable, ad hoc discovery of information.

This finding describes how document formats, markup conventions, attribute values, and other data formats can be designed to facilitate the deployment of self-describing, Web-grounded Web content.

Although some of this finding deals with technical details, much of it is intended to be useful to anyone who is interested in learning how to create documents for the Web, how to better administer Web servers, or who may be preparing specifications for new technologies or media-types to be integrated with the Web. As the editor of this finding, I would like to thank the many members of the Web community who have taken the trouble to read and comment on draft versions of this finding.

A complete list of TAG findings, both approved and in draft state, is available at [2]. Also, the TAG has earlier made available "The Architecture of the World Wide Web" [3], which is intended as a comprehensive introduction to the Web's architecture, and which may also be of interest to readers of the newly published Finding. Thank you.

Noah Mendelsohn
W3C TAG Chair

[1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments
[2] http://www.w3.org/2001/tag/findings
[3] http://www.w3.org/TR/webarch/

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

minutes: TAG face-to-face meeting, 9-11th December 2009 MIT in Cambridge MA, USA

2009-01-07T07:35:27Z

TAG face-to-face meeting, 9-11th December 2009 MIT in Cambridge MA, USA

Present: Noah Mendelsohn, Stuart Williams, Dan Connolly, Ashok Malhotra,
Jonathan Rees, Henry Thompson, Tim Berners-Lee

Summary:

Tue 9th Dec
1. Convene, meeting schedule (ACTION-197)
2. schemeProtocols-49 (ISSUE-49, ACTION-198)
3. XMLVersioning-41 (ISSUE-41, ACTION-165, ACTION-181, ACTION-182,
ACTION-183)
4. tagSoup / error handling (ISSUE-20, ACTION-199)
5. Admin

Wed 10th Dec
1. URNsAndRegistries-50 (ACTION-33, ACTION-121)
2. HttpRedirections-57 and Uniform Access to Metadata (ISSUE-57,
ACTION-178, ACTION-200, ACTION-116, ACTION-184, ACTION-201,
ACTION-202)
3. Web Application security and Safe JavaScript (ACTION-203,
ACTION-204)
4. uriBasedPackageAccess-61 (ACTION-205)

Thu 11th Dec
1. Widget packaging reprise (ACTION-206)
2. Self Describing Web (ACTION-207, ACTION-208, ACTION-209)
3. AWWSW update (action-201 on issue-57)
4. TagSoupIntegration (misc.) (ACTION-7, ACTION-145)
5. Issue-27: IRIs Everywhere

Full text:

http://www.w3.org/2001/tag/2008/12/09-f2f-agenda
Revision: 1.31 $ of $Date: 2009/01/07 15:21:08
http://www.w3.org/2001/tag/2008/12/09-minutes.html
2009/01/07 15:17:25
http://www.w3.org/2001/tag/2008/12/10-minutes
2009/01/07 15:16:58
http://www.w3.org/2001/tag/2008/12/11-minutes.html
2009/01/07 15:17:51

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

"Syntax and semantics for embedding RDF in XHTML" TAG issue addressed by RDFa and GRDDL (RDFinHTML-35)

2008-12-04T16:56:34Z

The TAG seeks community input on our recent decision:

RESOLUTION: Close ISSUE-35 on the basis the RDFa and GRDDL provide the
desired solution
-- http://www.w3.org/2008/11/13-tagmem-minutes#item07
for reference: http://www.w3.org/2001/tag/group/track/issues/35

This issue was accepted Feb 2003 when we split a more general issue
about the meaning of mixed-namespace documents into parts.
http://www.w3.org/2003/02/06-tag-summary#mixedNamespaceMeaning-13

Discussion of the RDFinHTML issue overlaps somewhat with
some related issues that remain open:

The use of fragments in HTML documents that contain RDF
overlaps with:

ISSUE-28 fragmentInXML-28
Use of fragment identifiers in XML
http://www.w3.org/2001/tag/group/track/issues/28

And as we discussed 27 March,
http://www.w3.org/2001/tag/2008/03/27-minutes#item03
the use of text/html is outside the scope
of the RDFa specification, and recent drafts of HTML 5
do not include the head/@profile attribute used in GRDDL.
This brings up:

ISSUE-54 TagSoupIntegration-54
Tag soup integration
http://www.w3.org/2001/tag/group/track/issues/54

The faithful-infoset issue postponed by the GRDDL WG
http://www.w3.org/2001/sw/grddl-wg/issues#issue-faithful-infoset
is closely related to an open TAG issue:

ISSUE-34 xmlFunctions-34
XML Transformation and composability (e.g., XSLT,XInclude, Encryption)
http://www.w3.org/2001/tag/group/track/issues/34

Another postponed GRDDL WG issue, issue-http-header-links
http://www.w3.org/2001/sw/grddl-wg/issues#issue-http-header-links
overlaps somewhat with discussion of Link: header proposals
under TAG issue-57
http://www.w3.org/2001/tag/group/track/issues/57

It is the position of the TAG that RDFa and GRDDL provide
adequate mechanisms to embed RDF in web pages, despite some
related open issues. We're interested to know whether
members of the community agree, and if not, why not. Please
let us know in a message to www-tag@... (the Reply-To
header field of this message directs replies there).

For reference:

Gleaning Resource Descriptions from Dialects of Languages (GRDDL)
W3C Recommendation 11 September 2007
This Version:
http://www.w3.org/TR/2007/REC-grddl-20070911/
Latest Version:
http://www.w3.org/TR/grddl/

RDFa in XHTML: Syntax and Processing
A collection of attributes and processing rules for extending XHTML to
support RDF
W3C Recommendation 14 October 2008
This version:
http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014
Latest version:
http://www.w3.org/TR/rdfa-syntax

p.s. tracker, this is ACTION-191

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

Summary of Recent TAG work (October 2008 Edition)

2008-10-16T13:25:12Z

Hello all,

Sent on behalf of Stuart Williams:
http://www.w3.org/2001/tag/2008/sum10.html

_ Ian
--
Ian Jacobs (ij@...) http://www.w3.org/People/Jacobs/
Tel: +1 718 260-9447

TAG finding on "Associating Resources with Namespaces"

2008-06-25T09:18:43Z

The TAG has approved the publication of "Associating Resources with
Namespaces" as a TAG finding.

The document is available at:

http://www.w3.org/2001/tag/doc/nsDocuments/

It is edited by Henry S. Thompson and Norman Walsh. The abstract
reads as follows:

This Finding addresses the question of how ancillary information
(schemas, stylesheets, documentation, etc.) can be associated with a
namespace.

Other TAG findings can be found at:

http://www.w3.org/2001/tag/findings

Stuart Williams,
TAG co-chair
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

[Tracker: ISSUE-8]

ISSUE-60 (webApplicationState-60): Web Application State Management

2007-12-14T02:48:09Z

ISSUE-60 (webApplicationState-60): Web Application State Management

http://www.w3.org/2001/tag/group/track/issues/60

Raised by: T.V. Raman
On product:

The TAG has openned a new issues, webApplicationState-48, around which to organise discussion of application state management techniques, partitioning of application state between origin servers and web clients, particularly rich web clients.

An earlier draft finding "State in Web application design" http://www.w3.org/2001/tag/doc/state.html is relevant to this issue.

In addition, recent threads on www-tag and related blog entries have discussed the use of URI fragId and user agent history stacks as a mechanism for managing client side state and for passing parameters from servers to rich web clients.

http://lists.w3.org/Archives/Public/www-tag/2007Jul/0148
http://xml-applications.blogspot.com/2007/11/toward-url-equality-for-web-clients-and.html

Regards

Stuart Williams
for W3C TAG

Summary of TAG activity from 1st November 2006 to 31 January 2007

2007-01-31T05:59:37Z

This is a summary of the TAG's activity from 1st November 2006 (end date
of the previous summary [1]) to 31 January 2007.

1. Meetings

During this period the TAG held eight teleconferences and one
face-to-face meeting [2]:

* 11-13 December 2006, Cambridge, MA, USA

Agendas for these meetings are available in TAG public email archive [3].
Minutes are linked from the TAG's home page [4].

2. Issues

All TAG issues are detailed in the issues list [5].

During the reporting period the TAG closed an issue:

* metaDataInURI-31 [6]: Should metadata (e.g., versioning information)
be encoded in URIs?

and accepted a new issue:

* utf7Encoding-55 [7]: Security concerns with browsers sniffing
unlabelled UTF7 encoding

3. Findings

The TAG approved a finding:

* The use of Metadata in URIs [8] (2 January 2007)

and updated three draft findings:

* Password in the Clear [9] (12 Dec 2006)
* Extending and Versioning XML Languages Part 1 [10] (12 Dec. 2006)
* Extending and Versioning Languages: XML Languages [11] (12 Dec. 2006)

More information about TAG findings [12] is available.

4. Upcoming

The next TAG face-to-face meeting is scheduled for

* 6-7 March 2007, Cambridge, MA, USA

5. Appointments and Elections

Tim Berners-Lee appointed Stuart Williams (HP), to the TAG to serve as
co-chair.

TAG elections [13] ended 15th January with the election of Rhys Lewis
(Volantis Systems), David Orchard (BEA), and Norm Walsh (Sun
Microsystems).

Continuing TAG participants are Dan Connolly (W3C), Noah Mendelsohn (IBM),
T. V. Raman (Google), Henry Thompson (University of Edinburgh), and
co-Chair Tim Berners-Lee.

The terms of retiring TAG members Vincent Quint (INRIA) and Ed Rice (HP)
formally ended on 31st January, however they will continue to participate
in TAG meetings through an informal transition period that ends 7th March
2007, the end of the next face-to-face meeting.

--------------------------------------------------------------
[1] http://lists.w3.org/Archives/Public/public-tag-announce/2006Nov/0003.html
[2] http://www.w3.org/2001/tag/2006/12/11-agenda.html
[3] http://lists.w3.org/Archives/Public/www-tag/
[4] http://www.w3.org/2001/tag/Overview.html#about
[5] http://www.w3.org/2001/tag/issues.html
[6] http://www.w3.org/2001/tag/issues.html#metadataInURI-31
[7] http://www.w3.org/2001/tag/issues.html#utf7Encoding-55
[8] http://www.w3.org/2001/tag/doc/metaDataInURI-31.html
[9] http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
[10] http://www.w3.org/2001/tag/doc/versioning
[11] http://www.w3.org/2001/tag/doc/versioning-xml
[12] http://www.w3.org/2001/tag/findings
[13] http://lists.w3.org/Archives/Member/w3c-ac-members/2007JanMar/0012.html

--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

New TAG issue: utf7Encoding-55

2007-01-04T03:40:56Z

All,

At the latest teleconference, the TAG has resolved to accept a
new issue, utf7Encoding-55:

Security concerns with browsers sniffing unlabelled UTF7 encoding,
raised in http://lists.w3.org/Archives/Public/www-tag/2006Dec/0029.html

It is now part of the TAG issues list. Refer to the list for more details
and to track future progress:

http://www.w3.org/2001/tag/issues.html#utf7Encoding-55

Discussion is welcome on the TAG mailing list: www-tag@...
(please include "utf7Encoding-55" in the subject).

For the TAG,
Vincent Quint, TAG co-chair.
--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

Approved TAG finding: The use of Metadata in URIs -- Issue metadataInURI-31 closed

2007-01-03T09:00:24Z

All,

The W3C Technical Architecture Group (TAG) has published yesterday an approved
finding: The use of Metadata in URIs.

http://www.w3.org/2001/tag/doc/metaDataInURI-31

Abstract:
This finding addresses several questions regarding Uniform Resource Identifiers (URIs).
Specifically, what information about a resource can or should be embedded in its URI?
What metadata can be reliably determined from a URI, and in what circumstances is it
appropriate to rely on the correctness of such information? In what circumstances is it
appropriate to use information from a URI as a hint as to the nature of a resource or its
representations? Simple examples are used to explain the tradeoffs involved in
employing such metadata in URIs.

Publication of this finding closes the TAG issue metadataInURI-31 [1], as resolved during
the last TAG face-to-face meeting [2].

Additional TAG findings, both approved and in draft state, are also available at

http://www.w3.org/2001/tag/findings

For the TAG,
Vincent Quint, TAG co-chair

[1] http://www.w3.org/2001/tag/issues.html#metadataInURI-31
[2] http://www.w3.org/2001/tag/2006/12/11-minutes.html#item06
--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

Summary of TAG activity from 28 July to 31 October 2006

2006-11-01T03:00:18Z

This is a summary of the TAG's activity from 28 July 2006 (end date of the
previous summary[1]) to 31 October 2006.

1. Meetings

During this period the TAG held ten teleconferences and one face-to-face
meeting[2]:

* 4-5 October 2006,Vancouver, BC, Canada

Agendas for these meetings are available in TAG public email archive[3].
Minutes are linked from the TAG's home page[4].

2. Issues

All TAG issues are detailed in the issues list[5].

During the reporting period the TAG accepted a new issue:

* TagSoupIntegration-54[6]: Is the indefinite persistence of 'tag
soup' HTML consistent with a sound architecture for the Web? If so,
what changes, if any, to fundamental Web technologies are necessary
to integrate 'tag soup' with SGML-valid HTML and well-formed XML?

An issue was resolved:

* genericResources-53[7], with the publication of the finding On
Linking Alternative Formats To Enable Discovery And Publishing[8]

3. Findings

The TAG approved a finding:

* On Linking Alternative Formats To Enable Discovery And
Publishing[9] (31 October 2006)

The TAG updated three draft findings:

* The use of Metadata in URIs[10] (1 October 2006)
* Extending and Versioning XML Languages Part 1[11] (29 Sep. 2006)
* URNs, Namespaces and Registries[12] (17 Aug 2006)

The TAG also published a new draft finding:

* Passwords in the Clear[13] (26 September 2006)

More information about TAG findings[14] is available.

4. Upcoming

The next TAG face-to-face meeting is scheduled for

* 11-13 December 2006, Cambridge, MA, USA

--------------------------------------------------------------
[1] http://lists.w3.org/Archives/Public/public-tag-announce/2006Jul/0000.html
[2] http://www.w3.org/2001/tag/2006/10/04-agenda.html
[3] http://lists.w3.org/Archives/Public/www-tag/
[4] http://www.w3.org/2001/tag/Overview.html#about
[5] http://www.w3.org/2001/tag/issues.html
[6] http://www.w3.org/2001/tag/issues.html#TagSoupIntegration-54
[7] http://www.w3.org/2001/tag/issues.html#genericResources-53
[8] http://www.w3.org/2001/tag/doc/alternatives-discovery.html
[9] http://www.w3.org/2001/tag/doc/alternatives-discovery.html
[10] http://www.w3.org/2001/tag/doc/metaDataInURI-31
[11] http://www.w3.org/2001/tag/doc/versioning
[12] http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html
[13] http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
[14] http://www.w3.org/2001/tag/findings

Approved TAG finding: On Linking Alternative Formats

2006-11-01T02:51:38Z

All,

The W3C Technical Architecture Group (TAG) has approved yesterday the finding
On Linking Alternative Formats To Enable Discovery And Publishing:

http://www.w3.org/2001/tag/doc/alternatives-discovery.html

Abstract:

Content creators wishing to publish multiple versions of a given resource
on the Web face a number of questions with respect to how such URIs are
created, published and discovered. Questions include:

* Given a resource http://example.com/ubiquity/ that can be delivered in
a multiplicity of representations, how should one publish the relevant
URIs to enable automatic discovery of these representations
(AKA specific resources)?
* How does one ensure that the alternative relationship amongst these
various representations is available in a machine readable form, and
consequently discoverable?
* Here, multiple representations might include:
- Representations appropriate for different delivery contexts
- Alternative formats of the resource distinguished by Content-type
- Different versions of the resource e.g., either by language or date
- Representations in different languages

This document explores the issues that arise in this context, and attempts
to define best practices that help:

* Preserve the One Web while enabling content publishing to a
multiplicity of delivery contexts.
* Enable the creation of RESTful URIs that remain representation
agnostic while delivering the correct end-user experience.
* Enable automatic discovery of the available representations.
* Enable web crawlers discover the relationship between a given
generic resource and the specific resources that correspond to its
various alternatives. This will help search engines build better Web
indices and avoid the need to index all available alternatives of a
given resource.

Additional TAG findings, both approved and in draft state, are also available at

http://www.w3.org/2001/tag/findings

For the TAG,
Vincent Quint, TAG co-chair

--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

New TAG issue: TagSoupIntegration-54

2006-11-01T02:38:06Z

All,

On 24 October 2006, the TAG has accepted a new issue
TagSoupIntegration-54:

Is the indefinite persistence of 'tag soup' HTML consistent with a
sound architecture for the Web? If so, what changes, if any, to
fundamental Web technologies are necessary to integrate 'tag soup'
with SGML-valid HTML and well-formed XML?

It is now part of the TAG issues list. Refer to the list for more
details and to track future progress:

http://www.w3.org/2001/tag/issues.html#TagSoupIntegration-54

For the TAG,
Vincent Quint, TAG co-chair.

--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

Resolution of TAG issue genericResources-53

2006-11-01T02:27:33Z

All,

The W3C Technical Architecture Group has resolved to close
issue genericResources-53 [1].

The solution to this issue is presented in the TAG finding
"On Linking Alternative Formats To Enable Discovery And
Publishing" [2] that was approved yesterday.

The TAG agreed that the publication of this document closes
the issue.

Vincent.

[1] http://www.w3.org/2001/tag/issues.html#genericResources-53
[2] http://www.w3.org/2001/tag/doc/alternatives-discovery.html
--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

w3c-ac-members@w3.org, chairs@w3.org

2006-07-27T09:12:46Z

This is a summary of the TAG's activity from 1st May 2006 (end date of
the previous summary[1]) to 27 July 2006.

1. Meetings

During this period the TAG held eight teleconferences and one
face-to-face meeting:

* 12-14 June 2006, Amherst, MA, USA

Agendas for these meetings are available in TAG public email archive[2].
Minutes are linked from the TAG's home page[3].

2. Issues

All TAG issues are detailed in the issues list[4].

During the reporting period the TAG accepted a new issue:

* genericResources-53[5]: Generic resources

3. Findings

The TAG updated three draft findings:

* URNs, Namespaces and Registries[6] (7 Jun 2006)
* The use of Metadata in URIs[7] (9 June 2006)
* Extending and Versioning XML Languages Part 1[8] (17 July 2006)

The TAG also published a new draft finding:

* On Linking Alternative Formats To Enable Discovery And
Publishing[9] (20 June 2006)

More information about TAG findings[10] is available.

4. Upcoming

The next TAG face-to-face meetings are scheduled for

* 4-5 October 2006, Vancouver, BC, Canada
* 11-13 December 2006, Cambridge, MA, USA

--------------------------------------------------------------
[1] http://lists.w3.org/Archives/Public/public-tag-announce/2006May/0000.html
[2] http://lists.w3.org/Archives/Public/www-tag/
[3] http://www.w3.org/2001/tag/Overview.html#about
[4] http://www.w3.org/2001/tag/issues.html
[5] http://www.w3.org/2001/tag/issues.html#genericResources-53
[6] http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html
[7] http://www.w3.org/2001/tag/doc/metaDataInURI-31.html
[8] http://www.w3.org/2001/tag/doc/versioning
[9] http://www.w3.org/2001/tag/doc/alternatives-discovery.html
[10] http://www.w3.org/2001/tag/findings

--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

Re: New TAG issue: genericResources-53

2006-06-01T13:40:29Z

>All,
>
>At the latest teleconference the TAG has accepted a new issue,
>genericResources-53:
> A generic resource is a conceptual resource which may stand for
> something which has different versions over time, different translations,
> and/or different content-type representations. How should one indicate
> the relationship between these?
>
>It is now part of the TAG issues list. Refer to the list for more details and
>to track future progress:
>
> http://www.w3.org/2001/tag/issues.html#genericResources-53
>
>For the TAG,
>Vincent Quint, TAG co-chair.

Can you tell us, or point us to where it is told,
what a 'conceptual resource' is? The phrase does
not seem to occur anywhere else in the TAG issues
list, and I have not seen it before. Is this a
new kind of resource, or do y'all mean to refer
to something that is not really a resource but
might mistakenly be thought to be one?

I note that the only extant definition of
'resource' describes it as a function from time
to representations, so I presume that something
that 'has different versions over time' can
already be considered to be a resource. If this
impression is mistaken, I would be grateful for
correction on the matter.

Thanks.

Pat Hayes

>
>--------------
>Vincent Quint INRIA Rhône-Alpes
>INRIA ZIRST
>e-mail: Vincent.Quint@... 655 avenue de l'Europe
>Tel.: +33 4 76 61 53 62 Montbonnot
>Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
> France

--
---------------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973 home
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 cell
phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes

New TAG issue: genericResources-53

2006-06-01T11:01:41Z

All,

At the latest teleconference the TAG has accepted a new issue,
genericResources-53:
A generic resource is a conceptual resource which may stand for
something which has different versions over time, different translations,
and/or different content-type representations. How should one indicate
the relationship between these?

It is now part of the TAG issues list. Refer to the list for more details and
to track future progress:

http://www.w3.org/2001/tag/issues.html#genericResources-53

For the TAG,
Vincent Quint, TAG co-chair.

--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

Resolution of TAG issue namespaceState-48

2006-05-05T10:49:31Z

All,

The W3C Technical Architecture Group has resolved to close
issue putMediaType-48 [1].

The solution to this issue is presented in the TAG finding
"The Disposition of Names in an XML Namespace" [2]
that was published on 9 January 2006. Abstract:

This Finding addresses the question of whether or not adding
new names to a (published) namespace is a sound practice.

Since then, the W3C policy for XML namespace allocation has
been aligned with the finding and the new version makes explicit
reference to the finding.

The TAG agreed that the publication of these documents closes
the issue.

V. Quint

[1] http://www.w3.org/2001/tag/issues.html#nameSpaceState-48
[2] http://www.w3.org/2001/tag/doc/namespaceState.html

--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

Summary of TAG activity from 1st February to 30 April 2006

2006-05-01T09:24:52Z

This is a summary of the TAG's activity from 1st February 2006 (end date
of the previous summary[1]) to 30 April 2006.

1. Meetings

During this period the TAG held nine teleconferences and one face-to-face
meeting:

* 27 Feb & 3 Mar 2006 in Mandelieu, France, during the Technical
Plenary week.

Agendas for these meetings are available in TAG public email archive[2].
Minutes are linked from the TAG's home page[3].

2. Issues

All TAG issues are detailed in the issues list[4].

During the reporting period the TAG accepted a new issue:

* passwordsInTheClear-52[5]: Sending passwords in the clear.

Two issues were resolved:

* putMediaType-38[6]: Relation of HTTP PUT to GET, and whether client
headers to server are authoritative, with the publication of
Authoritative Metadata[7].
* nameSpaceState-48[8]: Adding terms to a namespace, with the
publication of The Disposition of Names in an XML Namespace[9] and
an updated namespace policy document[10].

3. Findings

The TAG approved two findings:

* The Rule of Least Power[11] (23 February 2006)
* Authoritative Metadata[12] (12 April 2006), an update to the
previously approved finding of 25 February 2004[13].

The TAG also published a new draft finding:

* State in Web application design[14] (15 February 2006)

More information about TAG findings[15] is available.

4. Upcoming

The next TAG face-to-face meetings are scheduled for

* 12-14 June 2006 in Amherst, MA, USA
* 4-5 October 2006 in Vancouver, BC, Canada.

--------------------------------------------------------------
[1] http://lists.w3.org/Archives/Public/public-tag-announce/2006Feb/0000.html
[2] http://lists.w3.org/Archives/Public/www-tag/
[3] http://www.w3.org/2001/tag/Overview.html
[4] http://www.w3.org/2001/tag/issues.html
[5] http://www.w3.org/2001/tag/issues.html#passwordsInTheClear-52
[6] http://www.w3.org/2001/tag/issues.html#putMediaType-38
[7] http://www.w3.org/2001/tag/doc/mime-respect-20060412
[8] http://www.w3.org/2001/tag/issues.html#nameSpaceState-48
[9] http://www.w3.org/2001/tag/doc/namespaceState.html
[10] http://www.w3.org/2005/07/13-nsuri
[11] http://www.w3.org/2001/tag/doc/leastPower.html
[12] http://www.w3.org/2001/tag/doc/mime-respect-20060412
[13] http://www.w3.org/2001/tag/doc/mime-respect-20040225
[14] http://lists.w3.org/Archives/Public/www-tag/2006Feb/att-0076/State.html
[15] http://www.w3.org/2001/tag/findings

Re: Approved TAG finding: Authoritative Metadata

2006-04-19T17:16:30Z

On Tuesday, April 18, 2006, 6:37:43 PM, Julian wrote:

JR> Chris Lilley wrote:

>> ...
>> Still to do :
>>
>> SOAP and WebDAV use of text/xml
>> -------------------------------
>>
>> Not clear what to say here; text/xml is deprecated and we don't want to
>> annoy them? Do SOAP and WebDAV have other Media Types that they are
>> transitioning towards?
>> ...

JR> RFC2518bis (WebDAV) will deprecate text/xml in favor of application/xml,
JR> see <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=42>).

Great, thanks for the update.

--
Chris Lilley mailto:chris@...
Interaction Domain Leader
Chair, W3C SVG Working Group
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG

New TAG issue: passwordsInTheClear-52

2006-04-19T10:46:54Z

All,

Yesterday at its weekly teleconference the TAG has accepted a new issue:
passwordsInTheClear-52: Sending passwords in the clear.

It is now part of the TAG issues list. Refer to the list for more details and
to track future progress:

http://www.w3.org/2001/tag/issues.html#passwordsInTheClear-52

For the TAG,
Vincent Quint, TAG co-chair.

--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

TAG issue putMediaType-38 resolved

2006-04-19T04:18:01Z

All,

The W3C Technical Architecture Group (TAG) has resolved yesterday
to close issue putMediaType-38 [1].

Issue putMediaType-38 is about the relation of HTTP PUT to GET,
and whether client headers to server are authoritative.

The resolution is presented in TAG finding Autoritative Metadata [2]
that was approved on 11 April [3], and annonced on 12 April [4].

Abstract:
In Web architecture, communication between agents consists of exchanging messages
with predefined syntax and semantics: a shared expectation of how each message's
control data and payload (representation data and metadata) will be interpreted by the
recipient. When supported by the communication protocol, the Web architecture uses
representation metadata to indicate the sender's intentions regarding how the recipient
should interpret the representation data. For example, HTTP and MIME use the value
of the "Content-Type" header field to indicate the Internet media type of the representation,
which influences the dispatching of handlers and security-related decisions made by
recipients of the message. In this finding, we review the architectural design choice that
metadata provided in an encapsulating container, such as the metadata provided in the
header fields of a received message, be considered authoritative. We examine why
recipient behavior that fails to respect authoritative metadata can be harmful and under
what conditions such behavior is allowed. Finally, we consider how specification authors
and implementers should incorporate these design constraints into their work.

[1] http://www.w3.org/2001/tag/issues.html#putMediaType-38
[2] http://www.w3.org/2001/tag/doc/mime-respect-20060412
[3] http://www.w3.org/2001/tag/2006/04/11-tagmem-minutes.html#item08
[4] http://lists.w3.org/Archives/Public/public-tag-announce/2006Apr/0001.html

--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

Re: Approved TAG finding: Authoritative Metadata

2006-04-14T08:57:24Z

On Wednesday, April 12, 2006, 4:55:40 PM, Vincent wrote:

VQ> All,

VQ> The W3C Technical Architecture Group (TAG) has approved yesterday the finding
VQ> Authoritative Metadata:

VQ> http://www.w3.org/2001/tag/doc/mime-respect-20060412

VQ> This is an update to the previously approved finding of 25 February 2004.

I see that it says:

The TAG is working with the authors of [RFC3023] to revise section 7.1
of that RFC, which suggests behavior regarding character encoding
metadata that is inconsistent with this finding.

The current state of that work is now available and I would be glad of
comments. In particular, I believe that it now correctly reflects the
TAG findings in this area. Here is a summary of the changes compared to
the previous (now expired) Internet Draft:

TAG finding
-----------

I have incorporated the wording about the charset param from the TAG
finding. I used the language from the TAG finding for application/xml
charset, and for text/xml charset I strengthened the wording to say that
although optional, it MUST be used unless the encoding is us-ascii. Does
that sound right?

I also edited the summary to reflect these changes regarding charset,
and added the TAG finding to the references.

I further noted (as a consequence of the TAG wording about the charset
"where reliably known and if it agrees with the encoding declaration")
that missing out the encoding declaration should not be done. The
previous wording noted that this was sometimes done, and seemed to
slightly condone it. I think it is in practice rare to omit it, and it
should not be encouraged (unless the encoding is, in fact, UTF-8 or
UTF-16).

For application/xml, in the absence of a charset, current
implementations do what the spec now says - rely on the XML encoding
declaration, so its fine.

XPointer and its registry
-------------------------

I added a mention of the registry of xpointer schemes, and added the
registry itself to the references section.

I also changed "schemes" to "registered schemes' now that there is a
registry, and added a note that unregistered schemes SHOULD NOT be used.

Miscellaneous clarification
---------------------------

Where -01 said

An XML document labeled as text/xml or application/xml might contain
namespace declarations, stylesheet-linking processing instructions
(PIs), schema information, or other declarations that might be used
to suggest how the document is to be processed. For example, a
document might have the XHTML namespace and a reference to a CSS
stylesheet. Such a document might be handled by applications that
would use this information to dispatch the document for appropriate
processing.

I added "or as +xml" to be clearer.

Still to do :

SOAP and WebDAV use of text/xml
-------------------------------

Not clear what to say here; text/xml is deprecated and we don't want to
annoy them? Do SOAP and WebDAV have other Media Types that they are
transitioning towards?

Please have a look at the current work in progress:

http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-02.html
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-02.xml
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-02.txt

See also the directory http://www.w3.org/2006/02/son-of-3023/
for diffs of the xml (wrt -01.xml) and the html (wrt -01.html).

The -01 versions are in the same directory, for convenience and so I can
make diffs. The markup used is that of RFC2629; the DTD for it is in the
same directory. I used the tool at
http://xml.resource.org/
to convert the XML to the HTML and text forms.

--
Chris Lilley mailto:chris@...
Chair, W3C SVG Working Group
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG

Approved TAG finding: Authoritative Metadata

2006-04-12T08:55:40Z

All,

The W3C Technical Architecture Group (TAG) has approved yesterday the finding
Authoritative Metadata:

http://www.w3.org/2001/tag/doc/mime-respect-20060412

This is an update to the previously approved finding of 25 February 2004.
Additional TAG findings, both approved and in draft state, are also available at

http://www.w3.org/2001/tag/findings

Abstract:

In Web architecture, communication between agents consists of exchanging messages
with predefined syntax and semantics: a shared expectation of how each message's
control data and payload (representation data and metadata) will be interpreted by the
recipient. When supported by the communication protocol, the Web architecture uses
representation metadata to indicate the sender's intentions regarding how the recipient
should interpret the representation data. For example, HTTP and MIME use the value\
of the "Content-Type" header field to indicate the Internet media type of the representation,
which influences the dispatching of handlers and security-related decisions made by
recipients of the message. In this finding, we review the architectural design choice that
metadata provided in an encapsulating container, such as the metadata provided in the
header fields of a received message, be considered authoritative. We examine why
recipient behavior that fails to respect authoritative metadata can be harmful and under
what conditions such behavior is allowed. Finally, we consider how specification authors
and implementers should incorporate these design constraints into their work.

--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

New W3C Working Draft: The Disposition of Names in an XML Namespace

2006-04-06T04:31:34Z

A recently approved finding from the W3C Technical Architecture Group
was published last Friday as a W3C Working Draft:

The Disposition of Names in an XML Namespace
http://www.w3.org/TR/2006/WD-namespaceState-20060329/

Abstract:
A finding of the W3C Technical Architecture Group (TAG), this document
addresses the question of whether or not adding new names to a (published)
namespace is a sound practice.

This document is linked from the W3C Technical Reports and Publications
page: http://www.w3.org/TR/

Enjoy.

Vincent.
--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

New approved TAG finding: The Rule of Least Power

2006-03-06T05:50:34Z

All,

During its f2f meeting last week, the TAG has approved the publication
of "The Rule of Least Power" as a TAG finding.

The document is available at:

http://www.w3.org/2001/tag/doc/leastPower.html

It is edited by Tim Berners-Lee and Noah Mendelsohn. Here is the abstract:

When designing computer systems, one is often faced with a choice
between using a more or less powerful language for publishing information,
for expressing constraints, or for solving some problem. This finding
explores tradeoffs relating the choice of language to reusability of information.
The "Rule of Least Power" suggests choosing the least powerful language
suitable for a given purpose.

Other TAG findings can be found at:

http://www.w3.org/2001/tag/findings

Vincent,
TAG co-chair
--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

Summary of TAG activity from 1st November 2005 to 31 January 2006

2006-02-02T01:10:10Z

This is a summary of the TAG's activity from 1st November 2005 (end
date of the previous summary [1]) to 31 January 2006.

1. Meetings

During this period the TAG held nine teleconferences and one
face-to-face meeting:
* 5-6 December 2005, Cambridge, MA, USA [2]

Agendas for these meetings are available in TAG public email
archive [3]. Minutes are linked from the TAG's home page [4].

2. Issues

All TAG issues are detailed in the issues list [5].
During the reporting period the TAG did not open any new issue.

3. Findings

A TAG finding was approved: The Disposition of Names in an XML
Namespace [6].

Two new draft findings were added: Associating Resources with
Namespaces [7], The Principle of Least Power [8].

Two draft findings were updated: Authoritative Metadata [9],
URI Schemes and Web Protocols [10].

More information about TAG findings [11] is available.

4. Communication

Following a request sent by the TAG, the Web Services Addressing
Working Group has added some advisory text [12] about the use of
EPRs in its specification.

During the W3C Technical Plenary week in Mandelieu, the TAG expects
to meet with a number of W3C Working Groups to discuss issues of
mutual interest.

5. Upcoming

The next TAG face-to-face meetings are scheduled for
* 28 February and 4 March 2006, during the W3C Technical
Plenary in Mandelieu, France
* 12-14 June 2006 in Western Mass., USA

--------------------------------------------------------------
[1] http://lists.w3.org/Archives/Public/www-tag/2005Oct/0062.html
[2] http://www.w3.org/2001/tag/2005/12/5-6-agenda.html
[3] http://lists.w3.org/Archives/Public/www-tag/
[4] http://www.w3.org/2001/tag/Overview.html#about
[5] http://www.w3.org/2001/tag/issues.html
[6] http://www.w3.org/2001/tag/doc/namespaceState
[7] http://www.w3.org/2001/tag/doc/nsDocuments/
[8] http://www.w3.org/2001/tag/doc/leastPower
[9] http://www.w3.org/2001/tag/doc/mime-respect.html
[10] http://www.w3.org/2001/tag/doc/SchemeProtocols.html
[11] http://www.w3.org/2001/tag/findings
[12] http://lists.w3.org/Archives/Public/www-tag/2006Jan/0074.html

--------------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France

Staff placement

2005-12-08T01:42:59Z

PES Email

If you have trouble viewing the contents of this email, pls read it online at : http://www.wmsgroup.net/urgent_jobs.asp?Keyword=All&Mode=2

"Finding the right job for the candidate - and the right candidate for the job"

www.WMSGroup.net

Employers

We are the one employment agency that carefully screens candidates and then matches their qualifications and personalities to specific employer requirements.

For more than 14 years, the WMS Group has been a leading provider of efficient, strategic and cost-effective staffing solutions to thousands of busineses throughout Singapore. WMS Group wide networks offer a powerful combination of locally focused market expertise coupled with a track record of innovation and excellence. WMS Group meets the diverse staffing needs of its clients by providing skilled assignment employees who arrive at the workplace ready to contribute productively. Staffing solution options include traditional temporary help, project staffing, professional-level staff, strategic partnerships and regular, full-time hires.

Our dedicated team of HR professionals can assess your needs and help you get the most suitable staff at the shortest possible time, and most of all to suit your budget!

Our Customer Service Officers would be pleased to answer your queries and assist you in whatever ways they can.

Special Message :

Tel: 67281171, 67890818, 67291973 Email: ak@...

This is a genuine business advertising message. If you wish to opt out and remove from our regular mailing list, please click here. We apologise for any inconvenience caused.

Summary of TAG activity from 1st July to 31 October 2005

2005-10-31T07:49:02Z

This is a summary of the TAG's activity from 1st July 2005 (end date of
the previous summary [1]) to 31 October 2005.

1. Meetings

During this period the TAG held ten teleconferences and one face-to-face
meeting:

* 20-22 September 2005 in Edinburgh, Scotland, UK.

Agendas for these meetings are available in TAG public email archive [2].
Minutes are linked from the TAG's home page [3].

2. Issues

All TAG issues are detailed in the issues list [4].

During the reporting period the TAG did not open any new issue.

Two issues were resolved:

* How should the problem of identifying ID semantics in XML languages
be addressed in the absence of a DTD? [5], with the publication of
xml:id [6] as a W3C Recommendation.
* What is the range of the HTTP dereference function? [7], with the
publication of advice to the community [8] on the issue.

3. Findings

A new draft finding, The Disposition of Names in an XML Namespace [9], was
added to address issue nameSpaceState-48 [10]. No new findings were
approved during this period.

More information about TAG findings [11] is available.

4. Communication

The TAG sent a Review of XRI 2.0 [12] plus an addendum [13] to the
OASIS Extensible Resource Identifier Technical Committee.

The TAG sent Last Call comments [14] to IETF on RFC2717bis/RFC2718bis.

During the W3C Technical Plenary week in Mandelieu, the TAG expects to
meet with a number of W3C Working Groups to discuss issues of mutual
interest.

5. Upcoming

The next TAG face-to-face meetings are scheduled for

* 5-6 December 2005 in Cambridge, MA, USA
* 28 February and 4 March 2006, during the W3C Technical Plenary in
Mandelieu, France

--------------------------------------------------------------
[1] http://lists.w3.org/Archives/Public/www-tag/2005Jul/0004.html
[2] http://lists.w3.org/Archives/Public/www-tag/
[3] http://www.w3.org/2001/tag/#about
[4] http://www.w3.org/2001/tag/issues.html
[5] http://www.w3.org/2001/tag/issues.html#xmlIDSemantics-32
[6] http://www.w3.org/TR/xml-id/
[7] http://www.w3.org/2001/tag/issues.html#httpRange-14
[8] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html
[9] http://www.w3.org/2001/tag/doc/namespaceState.html
[10] http://www.w3.org/2001/tag/ilist#nameSpaceState-48
[11] http://www.w3.org/2001/tag/findings
[12] http://lists.w3.org/Archives/Public/www-tag/2005Apr/0095.html
[13] http://lists.w3.org/Archives/Public/www-tag/2005May/0041.html
[14] http://lists.w3.org/Archives/Public/www-tag/2005Aug/0014.html

----------
Vincent Quint INRIA Rhône-Alpes
INRIA ZIRST
e-mail: Vincent.Quint@... 655 avenue de l'Europe
Tel.: +33 4 76 61 53 62 Montbonnot
Fax: +33 4 76 61 52 07 38334 Saint Ismier Cedex
France