W3C

Technical Architecture Group Meeting @ TPAC 2010

01 Nov 2010

See also: IRC log

Attendees

Present
Noah Mendelsohn, Larry Masinter, Ashok Malhotra, Tim Berners-Lee, Dan Appelquist
Regrets
T. V. Raman, Jonathan Rees, Henry Thompson, John Kemp
Chair
Noah Mendelsohn
Scribe
Dan Appelquist, Larry Masinter

Contents


<trackbot> Date: 01 November 2010

<DKA> Scribe: Dan

<DKA> ScribeNick: DKA

TAG Election

<scribe> scribenick: DKA

Review of Activities at TPAC

Noah: re: HTML - HTML wg is running an unconference...

[discussion on possible topics at other working groups]

<noah> DKA: Based on Mountain View discussion, I sent email to following groups:

<noah> 1) Web apps

<noah> 2) Device apis

<noah> 3) geo location

<noah> 4) HTML

<noah> DKA: I got back notes from:

<noah> Frederick Hirsch (representing device APIs): meeting with us might be useful

<Yves> Geolocation/DeviceAPI meeting thu/fri

<noah> Art Barstow: send a personal note DKA

<noah> Device APIs is Thurs/Fri.

<noah> DKA: Thought I'd sit on part of DAP and geolocation

<noah> Ashok: "as of this writing, Web apps will not meet Monday Nov. 1"

<noah> ACTION: Noah to reach out to Device APIs chair to see about joint TAG session [recorded in http://www.w3.org/2010/11/01-tagmem-minutes.html#action01]

<trackbot> Created ACTION-494 - Reach out to Device APIs chair to see about joint TAG session [on Noah Mendelsohn - due 2010-11-08].

<noah> DKA: I was thinking of attending both Device APIs and geolocation

DAP Agenda: http://www.w3.org/2009/dap/wiki/TPAC10Agenda

<noah> DKA: see 6) Rulesets

<noah> Working session re issues. Which issues do we address and which don't we?

<noah> proposed RESOLUTION: publish FPWD of Privacy Rulesets

<noah> from http://www.w3.org/2009/dap/wiki/TPAC10Agenda

<lmm> The things I want to talk about are more general than their action items -- e.g., how to manage extensibility in APIs, interaction of policy based requirements like accessibility, privacy, security with API definitions

<noah> NM: I'll give Fred a choice of late morning, or after 3PM on Thurs.

Larry: re: DAP - I'd like to discuss extensibility and other architectural topics with them relevant to w3c - how we design specs.

<noah> NM: Yes, I'm really interested in extensibility design in the APIs

Dan: Rulesets stuff also could have applicability outside of dap.

Noah: Other working groups?

Larry: could we constructively use our discussion with the IETF participants ...

Noah: We could suggest to the webapps group that IETF could be a resource...

Larry: the areas of security and privacy cut across the protocol boundaries...

Noah: What role for the TAG then? Matchmaker - but should TAG get out of the way then?

Larry: There's some interaction between policy and threat analysis that seems to cut across working groups... Broader topic than just the TAG can take on. Could the TAG take on a role as a gathering place of technical requirements in our interactions with IETF?

Tim: in playing a connecting role -- [with ietf] - maybe not the core mission [of the tag] but good for building up information on who does what...

Larry: We need some architectural advice for how to promote new protocol elements in a way that is secure and promotes privacy. Individual working groups come across these issues. Therefore if there weren't any outside group it would be the responsibility of the TAG. But there is a broader community with complementary expertise [ietf, iab, isoc, etc...] so we shouldn't do that work alone.
... when it comes to webapp architecture and the security implications of local storage and confused deputy attacks that we shouldn't do that analysis alone.

<lmm> suggest agenda for joint meetings: to solicit requirements from them, what things do they think TAG can help

Noah: Proposing Dan and Ashok show up at beginning of HTML working group (thursday morning) and see what is being proposed as agenda items - send out to TAG member list if there are items which might have TAG interest...

Larry: alternative proposal - meet with anyone who wants to meet with The TAG.

<lmm> unlikely to get interest?

[Ashok and Dan at minimum will go to agenda setting session for HTML]

XML Processing Model

<noah> DKA: I'll be at GeoLocation

<noah> DKA: Not sure how to juggle my Thurs/Fri schedule

<scribe> ACTION: Dan to organize something with Geo for Friday morning. [recorded in http://www.w3.org/2010/11/01-tagmem-minutes.html#action02]

<trackbot> Created ACTION-495 - Organize something with Geo for Friday morning. [on Daniel Appelquist - due 2010-11-08].

Tim's XML/HTML Talk and the Taskforce

Tim: slide content come from the white board discussion in Mountain View...
... support the community using xml tool chain...

Dan: Do we have numbers of people using XML tool chains?

Yves: Not to consume HTML -

Dan: The so-called round-tripping.

Noah: Should we talk about the philosophical differences - HTML community might say they value syntactic convenience...

Larry: I have some slides on divergent directions - touches on divergence between HTML and XML communities... Looking at it from divergent perspectives - what communities want.

Noah: [Suggesting some more discussion around the scope and operation of the taskforce]

Larry: [commenting on taskforce scope] W3c has invested a lot of energy around XML - tools around XML, applications around XML, XML knowledge: we want to make sure that that investment is brought to bear in the HTML community as well.

Noah: We should say: we could consider what should change on the XML or namespaces side as well as on the HTML side. For example, certain namespaces defaulted.

Yves: We already have XML-related specifications that are able to work on documents. HTML is a kind of documents. To avoid getting through the same issue sand redeveloping the same stack for HTML it would be good to create links between XML and HTML as is. How do we bring these together to make things better?

Tim: Maximize the total value.

Larry: We should be clear that the task force doesn't start with the answer.
... [previews his slides for TPAC panel on HTML Next]

Yves: Postel's law - be lenient on what you accept and strict on what you produce. The HTML group has defined precisely what leniency means in this context.

[Back from Break]

Noah: This will play out, HTML5 will continue, success criteria is that it comes up with something useful in the medium to long term.

Tim: Yes.

Noah: What should we say about success criteria?
... I think we should say we expect to produce design proposals...

Yves: is one of the goals to find a less disruptive way to achieving that?

Dan: +1 to leaving the door open to changes to "XML"

Yves: Is there an easy way to achieve XML HTML integration? Less disruptive solutions - could gain acceptance by both the HTML and XML communities?

Noah: Solutions that would be accepted by both communities - is good wording.

Dan: Worried about the perception of intransparency...

Noah: The [taskforce] should work in public.
... the mandate the taskforce has is to suggest solutions.

[discussion on xHTML basic - in mobile browsers - what the error handling is generally like]

Larry: Maybe we should have an interest group as well for people to raise issues and make sure that their issues are addressed.

Tim: Raman wanted to raise some realization in the community at the cost of having two stacks.
... in this context it's useful to think about long term solutions.

[discussion on whether you can use new features as a lever for clean markup]

Tim: in the blogosphere people are asking "does w3c validation increase your SEO?"
... using RDFa could be that lever.

<noah> Raman's note: http://lists.w3.org/Archives/Member/tag/2010Apr/0038.html

<lmm> http://www.w3.org/2001/tag/group/track/actions/428

<lmm> action-428 on distributed extensibility

<noah> Raman's note to AC Forum: http://lists.w3.org/Archives/Member/w3c-ac-forum/2010AprJun/0073.html

<timbl> Tracker please attach http://lists.w3.org/Archives/Member/w3c-ac-forum/2010AprJun/0073.html to ISSUE-54

ISSUE-67?

<trackbot> ISSUE-67 -- HTML and XML Divergence -- open

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

<lmm> scribe: Larry

<lmm> scribenick: lmm

note agreement to meet w/webapps at 4 PM

TAG output

Noah: we have had many good ideas about things the TAG should do, but as chair I find it hard to deliver on those
... and the elections make this even more difficult
... some of what was lost was lost when we went to more informal processes
... one way to handle this is to go to back to more formal publication

TBL: Larry proposed having -- for each thing on the agenda -- a proposed deliverable
... What about for each issue, having a deliverable for the issue

Noah: we are doing something like that, in a number of areas we've tried to do something like that -- we wrote a first draft that never tried to be comprehensive
... .... that was a year ago, where people have taken assignments to do some writing...

Ashok: use that work as part of the webapps finding, e.g., if we have agreed to a webapps finding

Noah: we've always deferred the packaging. I'd assumed what we would do on webapps would be more like the size of web architecture... between 5 and 20 pages

Larry: I want to have committed deliverables with (a) nature of deliverable and (b) realistic date for accomplishing it

Noah: We then need people to commit to delivering. Like with the MIMe document, I see that happening, but that's been the exception
... could we do that... for each open action... should we be able to do that

(discussion of nature of scheduling...)

Larry: I'm more interested in keeping schedule and possibly falling back on quality....

Ashok: My difficulty is getting reviews... write something and it falls into black hole

<noah> NM: As a tracking mechanism, I could typically track two actions: one long term for the complete result, linking to the detailed goals; the other short term for the next draft

<noah> NM: As a tracking mechanism, I could typically track two actions: one long term for the complete result, linking to the detailed goals; the other short term for the next draftLMM: My focus is more on the quality of the result than on the date

((I think keeping a schedule will help motivate review))

<noah> LMM: We should have output regularly

<noah> AM: Difficulty in getting reviewing

LMM: one possibility is that we'll talk about fewer things

<noah> ACTION: Noah to update Guide to TAG participation on intent to set specific deliverables for each discussion [recorded in http://www.w3.org/2010/11/01-tagmem-minutes.html#action03]

<trackbot> Created ACTION-496 - Update Guide to TAG participation on intent to set specific deliverables for each discussion [on Noah Mendelsohn - due 2010-11-08].

the "deliverable" could be the associated action

on action-496 should explicitly not only list deliverable but also intended date.

<DKA> List of TAG "products" (outputs) : http://www.w3.org/2001/tag/group/track/products

The TAG "products" are not specific documents, and none of them have an estimated delivery date

<noah> NM: Go back to producing a few more findings

DKA: makes sense to link output to products. We've used this with good effect in best practices.

Noah: DanC seemed to have opened products for "big issues"... we could change practice, but it's not been our tradition

((discussion about organizing TAG tracker))

Noah: remind me if I don't do this

taking Web apps forward

Ashok: I had thought we were slowly working toward a web apps document -- njot a "finding"

Noah: What I thought was "We have an architecture of the World Wide Web, we should enhance that, and we'll determine which of those would modify the architecture, and which would wind up with a separate document". Now, a year later, here we are.

Ashok: We can speak about how to go forward.

Ashok (on board): Web Apps Doc: Intro, Interaction, Client-side Storage, Client-Side State. JohnK was working on Intro & Interaction.

Ashok: I can write these (Client-side Storage/State), using Raman's document, and put these out.
... Is this a reasonable way to go forward ? Do we need to fill in more stuff.

Noah: we have the table of contents. There's a lot more to do. Even with the limited amount of stuff. I agree this is a pretty thin slice on what we have to do.

Ashok: (a) What do we do with JohnK's pieces (Intro & Interaction)
... (b) are there other things that people could take on
... and (c) can we publish these (Client-side storage & state) as findings?

action-461?

<trackbot> ACTION-461 -- Daniel Appelquist to draft "finding" on Web Apps API design -- due 2010-12-31 -- OPEN

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

action-480?

<trackbot> ACTION-480 -- Daniel Appelquist to draft overview document framing Web applications as opposed to traditional Web of documents Due: 2010-11-01 -- due 2010-10-27 -- OPEN

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

<noah> ACTION-434?

<trackbot> ACTION-434 -- Daniel Appelquist to prepare discussion of structure of what we want to do about web apps architecture... -- due 2010-10-18 -- OPEN

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

<noah> ACTION-488?

<trackbot> ACTION-488 -- Daniel Appelquist to solicit at TPAC perspectives on what TAG could/should do on APIs Due: 2010-11-09 -- due 2010-10-28 -- OPEN

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

I think these are all part of http://www.w3.org/2001/tag/group/track/products/7

<noah> close ACTION-434

<trackbot> ACTION-434 Prepare discussion of structure of what we want to do about web apps architecture... closed

noah: if you want to make a new product, that's fine, but i don't want to re-use old catch-all products

DKA: we should *not* have a new "web application architecture" product, but instead a set of products.
... the way to use the tracker is to make new products for the findings

Noah: we had a longer table of contents... there are other big things such as security, that are important to the community, that we've only just begun to touch on ....
... ... we owe it to the community to review to make sure we're working on the ones that are most important.

Ashok: what would we like ideally vs. what we can reasonably complete soon

Noah: I would like to split the security issues around storage...
... most of the people need to agree on the goal before we can get going on a topic

Ashok: My fear is that if we split out security, i tmight never get touched on again
... I would rather leave it in, unless someone steps up to do the security issue... e.g., one of the future tag members, because it might drop off

<noah> Sept 21, 2010: Table of contents for Web Apps

<noah> June 9, 2010: http://www.w3.org/2001/tag/2009/06/webAppsTOC-20090625

<noah> Sept 21: http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921

((discussion of outlines))

Noah: how do we organize the findings? ((alternatives not clear))

http://www.w3.org/standards/webarch/

Larry: Proposal: publish outline on w3c web site

noah: We should work on the outline
... we're not making enough progress on the whole
... of course 9 people aren't going to nail this in a year

sometimes we'll talk about the whole thing, and sometimes about minor things

Noah: I'd like to be able to stay that, in a year from June, we would publish a document on the scale of "the architecture of web applications", and that we'll have pieces done in less time than that

ashok: every two months we have a revision and review

noah: to have something final by a date, with some agreement of some sort, you have to have it pretty final a few months earlier
... findings should have 3-4 stories (example metadata in URIs)
... if we can get to the point that, for each of these, we can do that....

dka: not sure that the audience for all of these documents is the same... in some cases the audience is spec writers, and might need to have something shorter term, while some of these other things are aimed more at web application developers
... i'm aligned with having deliverables, i'd like to have more live editing sessions, to insure deliverables get done

noah: with respect to one or two actions you (DKA) have, what's your comfort level with having one?

dka: should have a deliverable for time frame for API design... sooner rather than later.
... the scope informs the timeline.... if we want to have a larger discussion about extensibility... if there's a tactical thing we have to address right now, then we might need to move sooner.
... I don't know that i wouldn't....

noah: I accept 75% or 80% of the spirit of what you (Larry) are asking for. I'm not guaranteeing, but I will try to do more to get more deliverables....

logistics

Thursday morning, Ashok & DanA monitor HTML agenda setting, alert us by email

find Norm for "XML processing"

call into Fred with Device APIs

2 PM with Alexey on Thursday (IETF)

Friday meeting in morning, pick up Privacy & MIME draft

DanA: reach out & find out

adjourn

Summary of Action Items

[NEW] ACTION: Dan to organize something with Geo for Friday morning. [recorded in http://www.w3.org/2010/11/01-tagmem-minutes.html#action02]
[NEW] ACTION: Noah to reach out to Device APIs chair to see about joint TAG session [recorded in http://www.w3.org/2010/11/01-tagmem-minutes.html#action01]
[NEW] ACTION: Noah to update Guide to TAG participation on intent to set specific deliverables for each discussion [recorded in http://www.w3.org/2010/11/01-tagmem-minutes.html#action03]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/11/19 09:19:46 $