W3C

- DRAFT -

Widgets Voice Conference

25 Sep 2008

Agenda

See also: IRC log

Attendees

Present
Art, Bryan, Marcos, Thomas, Benoit, Mark
Regrets
Arve, Nick, David, Claudio
Chair
Art
Scribe
Art, tlr

Contents


 

 

<ArtB> Date: 25 September 2008

<ArtB> Scribe: Art

<ArtB> ScribeNick: ArtB

<tlr> ScribeNick: tlr

Announcements

artb: reminder, go ahead and register for TPAC

<ArtB> AB: registration list: http://www.w3.org/2002/09/wbs/35125/TPAC2008/registrants#webapps

benoit: I think I'm registered

artb: Marc, Claudio, most of the usual suspects are registered
... obvious omissions at this point are the OMTP folks ...
... about 19 people registered as members of the WG ...
... will split up meeting; not everybody will attend widget part ...

benoit: half/half?

artb: unlikely. 90/10
... interested in any discussions related to access-control and xhr2 specs ..
... maybe a big joint meeting for that discussion ...
... let's see how things unfold over the next few weeks ...
... also, Larry Masinter will be attending the meeting ...
... registered as observer for Tuesday ...
... believe that Larry is member of TAG ...
... any other announcements?

Widgets core API and events status

per http://www.w3.org/2001/tag/#Membership, Larry Masinter is not a member of the TAG

artb: marcos, can you give us any update?

marcos: nope

artb: will prod Arve
... we're past the planned deadline for publishing ...

<scribe> ACTION: art to ping Arve regarding status of core API and events specification [recorded in http://www.w3.org/2008/09/25-wam-minutes.html#action01]

<trackbot> Created ACTION-252 - Ping Arve regarding status of core API and events specification [on Arthur Barstow - due 2008-10-02].

automatic updates

<scribe> Scribe: tlr

marcos: dotting t's, crossing i's
... should have something ready later today ...
... started working on processing model ...
... put in a bunch of red blocks to show where we're going ...

<mpriestl> +q

marcos: think it's ready for FPWD ...

artb: noticed request to webreq already

tlr: transition request?

artb: not yet, and confused publication requests
... what are the prerequisites?

tlr: reasonably stable editor's draft, SOTD, Abstract
... there can be some editorial fine-tuning

artb: marcos, please let me know when you're ready

marcos: couple hours

mpriestl: Marcos, we discussed a while ago about text on security of updates
... have something in draft ...
... but need a few more days to finish ...
... should be available by Monday ...

marcos: for the automatic update spec?

mpriestl: yes

marcos: wait?

mpriestl: don't want to hold up things
... will send to list on Monday or as soon as I can ...

artb: recommend not to block publication on this
... as soon as document is published, that would be a good time for Marc to send comments

mpriestl: agree

marcos: agree

artb: looking forward to that input

digsig spec

marcos: have been discussing various approaches ...
... particularly in relation to including multiple signatures ...
... and dealing with cert chains ...
... we haven't drafted anything quite yet ...
... plan to work on that soon with Marc ...
... priority to getting second Last Call of Requirements out ...
... and auto-update FPWD ...
... no spec language yet, but think we have a model and can start spec'ing ...

mpriestl: fyi, BONDI f2f discussed the spec
... position at the moment (which we hope to formally communicate this week) ...
... is that we hope to adopt W3C solution in BONDI ...
... will be officially communicated later this week ...

artb: in the agenda, listed a couple issues

ISSUE-19?

<trackbot> ISSUE-19 -- Widgets digital Signatures spec does not meet required use cases and requirements -- OPEN

<trackbot> http://www.w3.org/2008/webapps/track/issues/19

ISSUE-22?

<trackbot> ISSUE-22 -- Is sha1 as a DigestMethod strong enough for Widgets digital signatures? -- OPEN

<trackbot> http://www.w3.org/2008/webapps/track/issues/22

artb: discussed these most recently in Turin; don't necessarily want to do deep dive

<ArtB> Issue #19 discussion from Turin: http://www.w3.org/2008/08/27-wam-minutes.html#item06

marcos: ISSUE-19 -- we now have a clearer idea of what the UC&R's are
... will put things into the spec some time soon ...
... want to list what the use cases are ...
... basically, think that our current model addresses things ....
... but need to spec it out ...
... wrt ISSUE-22, can close that -- agreement that SHA1 is not the only digest in town ...

mpriestl: question for Thomas, you said that in the update to dsig spec, might specify sha-256
... any update? ...
... or any reason?

<ArtB> Discussion re Issue #22 from Turin is: http://www.w3.org/2008/08/27-wam-minutes.html#item07

tlr: no progress quite yet, also, I seem to recall that there was something about algorithm URIs

<ArtB> Here is the action I accepted re Issue #22 http://www.w3.org/2008/08/27-wam-minutes.html#action05

artb: yes, still want to do that
... put this item on the agenda for today to see whether I still should ask that question ...

tlr: that would be a good idea

artb: will put together e-mail today
... anything else?

Packaging and config

marcos: not too much new to report
... updated some things; latest draft not yet submitted ..
... working on the URI problem ...
... re-reading URI spec, making sure terminology is in line with that ...

artb: marcos, it would be helpful if you could go ahead and upload current snapshot
... even if not perfect yet ...
... drafts are by definition fluid and all that ...
... latest draft is a couple months old ...

marcos: usually submit source version fairly regularly ...
... source version is usually current ...
... if you want to see bleeding edge, look at source version ...

artb: want to be able to show some of the latest and greatest thoughts
... nice to be able to be more specific
... is the source-to-html process a lot of manual work?

marcos: no big deal

artb: we'd much appreciate if you could make that update more often

marcos: will do
... Interested in talking about e-mails, in particular the ones from i18n
... affect auto update ...
... would like to talk about this ...
... start with Felix' message ...

<ArtB> Felix comments: <http://www.w3.org/mid/48C86720.70206@w3.org>

<ArtB> ... from the archive: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0626.html

marcos: we asked about span vs Unicode characters
... they said the Unicode characters are a really bad idea
... recommend use of its:span
... it does add another level of complexity
... need to talk about how we actually address that ...

http://www.w3.org/TR/2007/REC-its-20070403/#span

marcos: could also be silent on this, leave it to implementers
... there are conflicts with the current algorithm ...
... currently, we build a big text string out of elements inside ...
... this is for error handling reasons ...
... can relax algorithm in the future ...
... not sure that's the best approach ...
... modelled on HTML5 parsing algorithm ...

tlr: "the algorithm" was what?

marcos: config document
... if author puts HTML / XHTML tag inside description ...
... and engine doesn't know how to deal with this ...
... just grabbing text content

tlr: is the concern about HTML, then?

marcos: either introduce bdo or span explicitly within this spec
... but that would imply changing the parsing algorithm ...
... explicit introduction of new element ...

tlr: mhhh.. that sounds like an awfully broad extensibility model for descriptions
... maybe tighten that ...
... but not sure I understand the point well enough right now to make the argument ...

artb: interoperability concern around this
... ITS support, etc ...

just to be clear, I'm happy with ITS, but wonder whether "arbitrary XML stuff" is the right approach for the description

artb: want to have feed-back from arveb
... please follow up on the mailing list ...
... this might be a specific agendum for Cannes ...
... may try to drag I18N folks into the room.

marcos: would prefer to resolve this before then
... once the update spec is out, will try to work on packaging spec

tlr: I think there's a requirements question here about what kind of material goes into the description

marcos: description of what the widget does, maybe some arabic

tlr: concern is that permitting arbitrary XML content there could get messy
... concern is not about ITS, though ...

artb: agree; maybe KISS for v1

<ArtB> Here is Dom's input re the P&C spec: http://www.w3.org/mid/1221556815.6777.88.camel@localhost

<marcos> AB: other comments we need to look at are from Dom

<ArtB> ScribeNick: ArtB

AB: we've discussed the HTML5 reference issue before; I'm concerned about it for this spec as well as other specs in progress

MC: we have two options:
... 1. We don't care

<marcos> MC: there are two minds on this: one is we don't care about going to REC and keep referencing HTML5; the other is that we copy and paste the bits we like HTML5 into our spec.

MC: 2. We copy-and-paste text from HTML5

AB: it seems like option #2 is our only really option

<tlr> ScribeNick: tlr

benoit: is there a way that we can get along without a reference to HTML5?

marcos: it'll take a loong time

benoit: want to make sure we're adaptive enough

artb: if we need to copy and paste from HTML5, note that this is the algorithm

marcos: will look more closely

benoit: instead of copying and pasting...

tlr: is content sniffing really needed in the widget spec?

marcos: we don't have a manifest...

tlr: I think this is a more general point
... maybe raise it more generally?

marcos: there's some discussion going on

tlr: ah, interesting!

artb: plan in turin was to advance as much as possible, so ready to request LC soon after Mandelieu

AOB

marcos: Bryan on the call; maybe he can give us update on MWBP
... what happened to our feed-back ...

Bryan: happy to adapt things; guidelines to developers on how widget APIs are used
... we can make some recommendations as to how they do things ...
... some of the things we suggested be firm requirements ...
... the other thing, within the scope of OMTP, have ability to make ...
... requirements on implementations ...
... couple ways to establish requirements ...
... undestand focus of webapps and widgets to be on packaging ...
... not so much behavior or best practices ...
... possible that we promote interoperability, efficiency etc
... usability aspects within this group ...
... torch carried by MWI ...

artb: that sounds like a useful split of work ...

bryan: re uaprof, specifying user agent, can specify behavior for XHR aPI
... don't need to do that within widget spec itself ...

artb: bryan, coming to Mandelieu?

bryan: conflicts with OMA meeting

marcos: for purposes of disposition of comments, was MWBP group happy with feedback?

bryan: will send question to list today
... won't be in meeting today ...
... can get them to ask that question to get closure ...
... my sense is that they understood focus, and scope of influence ...
... better understanding now ...

next meeting

artb: next week, same time

Summary of Action Items

[NEW] ACTION: art to ping Arve regarding status of core API and events specification [recorded in http://www.w3.org/2008/09/25-wam-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/09/25 11:58:17 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Art
Found ScribeNick: ArtB
Found ScribeNick: tlr
Found Scribe: tlr
Inferring ScribeNick: tlr
Found ScribeNick: ArtB
Found ScribeNick: tlr
Scribes: Art, tlr
ScribeNicks: ArtB, tlr
Default Present: +44.771.751.aaaa, Art_Barstow, Thomas, Bryan_Sullivan, Marcos, Benoit
Present: Art Bryan Marcos Thomas Benoit Mark
Regrets: Arve Nick David Claudio
Agenda: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0715.html
Found Date: 25 Sep 2008
Guessing minutes URL: http://www.w3.org/2008/09/25-wam-minutes.html
People with action items: art

[End of scribe.perl diagnostic output]