See also: IRC log
<trackbot> Date: 01 November 2010
<DKA> Scribe: Dan
<DKA> ScribeNick: DKA
<scribe> scribenick: DKA
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]
<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: 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
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
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....
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