W3C

- DRAFT -

Widgets Voice Conference

30 Oct 2008

Agenda

See also: IRC log

Attendees

Present
Art, Arve, Claudio, Mark, Marcos, Josh, Bryan
Regrets
Thomas, David, Jere
Chair
Art
Scribe
Art

Contents


 

 

<timeless> zakim +??P18 is Marcos

Date: 30 October 2008

<scribe> Scribe: Art

<scribe> ScribeNick: ArtB

<arve> +??P19

<timeless> zakim +39.011.228.aaaa is Claudio

Agenda review

AB: any changes?

[None]

Annoucements

AB: any annoucements?

<timeless> # who is on the phone?

<timeless> who is on the phone?

AB: Workshop deadline is now Nov 5

<timeless> Zakim: who is on the phone?

AB: who plans to submit a Position Paper?

<Bryan> very noisy

<arve> ArtB: Arve just spoke, and I said we were planning on submitting a position paper

AB: am I the only one that cannot understand anything that is being said?

<Bryan> I can't understand either

<arve> muting me didn't help

<arve> I can't understand a word being said

<Bryan> I hear a 2nd conversation

AB: everyone hang up and re-dial, please !

<Bryan> OK

<marcos> Arve, you are very noisy

AB: is anyone going to submit a PP for the workshop?

MC: I will

AB: how about Vodafone?

MP: no

Arve: I believe Opera will submit a paper

JS: no

Bryan: we may submit something but we won't be present

CV: we won't submit a paper but are very interested in the outcome

URI scheme

AB: we had a good conversation with TAG last week
... would like to know what people think are the next steps for this issue

MC: I think we have enough technical arguments to push forward
... we do need to fleshout the reqs
... We may also want to coordinate with other groups
... e.g. the ODF group
... they need a similar URI scheme
... for packaging

<timeless> ack

BS: we recognize (in OMA) that some type of URI scheme for widget interaction is needed

CV: I agree with Marcos and Bryan
... I think a widget-specific URI scheme would be useful

JS: I haven't changed my mind
... agree we need to flesh out the reqs

<marcos> Arve, you might need to type out your answer

<arve> ArtB: Your assesment of my opinion is essentially correct

AB: I'd like to understand the ODF coordination point

MC: I've had some conversations
... I don't want to block on them or create a dependency
... I will continue to talk with them

AB: are there some actions we can assign?

MC: think we need to look at the implications vis-a-vis the API spec
... we use the widget URI scheme to resolve the DOM at run time
... this affects the APIs we will define

Version String

AB: Marcos http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0183.html
... where are we on this?

MC: there were no strong objections

AB: OpenAjax recommend we consider their model?

MC: they proposed another way to write the scheme
... they have a proc model for version strings
... Arve showed their model has problems
... I want to follow the KISS principle

AB: I propose we agree with Marcos' version string proposal
... any objections?

JS: what about leading zeros?

MC: they are just opaque strings

AB: Josh, please enter an example

<timeless> MIDlet Suite Versioning suggests:

<timeless> Major.Minor[.Micro] (X.X[.X])

<arve> Does this mean any string difference is "a new version"

MC: we aren't adding that complexity
... If they are differen, then they are different

<timeless> do we need to suggest that we're aware that leading zeros are ignored by MIDlet

<timeless> and that people should avoid using leading zeros (or at least inconsistently)

<arve> What I actually meant is that "new" is that the UA, or the server, can decide whether it's "newer" or no

<arve> +t

AB: Marcos, what do you think about JS' recommendation?

MC: we can recommend a format
... and that there is no special processing

<arve> yes

<Bryan> +1

AB: can we live with the model Marcos has proposed?

JS: yes

<timeless> yes

<claudio> yes

RESOLUTION: Marcos' proposal for version string is acceptable

ID attribute

AB: http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0184.html
... there was no follow-up discussion
... see also http://krijnhoetmer.nl/irc-logs/webapps/20081027

MC: the question is about whether xml:id should be used or we define our own ID attribute

JS: could "name" be used?

MC: we already have a name element
... we would have to rename that to "title" element

<timeless> ack

BS: are we planning to use the title attribute in a semantic way?

MC: no, just a name

<claudio> +q

AB: Marcos, should you followup and make the proposal you and Josh just discussed?

MC: yes, I can do that
... we are currently following what other people are doing
... but I'd like to hear from others

CV: will there some semantics about the widget in the config doc?
... Req #12 is related to widget semantics

MC: no, not at this point

CV: so the manifest is extensible?

MC: yes, can add other elements

<timeless> ack

MC: the name element could be use in that use case

BS: there is a core set of metadata attributes already defined
... and it is extensible

MC: right, via using another namespace

AB: are you still looking for more input, Marcos on your ID attribute proposal?

MC: I can make the change if people are OK with it

<arve> did the channel just go dead?

MC: my fear is confusing widget authors

<arve> I'll have to give up on this, all audio just disappeared

<marcos> MC: widgetid

AB: what is your proposal?

<marcos> MC: uid

<marcos> MC: name

<marcos> CV: wid

AB: I am mostly indifferent

MC: it is a URI to identify the widget

JS: could use href

MC: but that implies something that http can get

<timeless> ack

BS: so you want something that is unique, right

MC: yes

BS: what about uniqueid then?

MC: yes, we could
... that's what I meant by "uid"

<marcos> arve, do you have an opinion?

MC: Are we providing at leas a non-normative suggestion about how to add semantics to the widget?

<arve> leaning towards making it "just a string"

<arve> I do not like the notion of saying it's an ID

<marcos> arve, what would you call it?

<marcos> ok, no probs

AB: I propose you make a proposal on the mail list with a default resolution

MC: OK

DigSig

AB: I will take 4.a and 4.b agenda items to the mail list

MC: Mark and I have been making some edits
... need comments from XMLSec WG
... perhaps that can be done while I am away

AOB

AB: Marcos will be offline for the next three weeks; not online again until 21 November
... I will decide on Tues or Wedn of the next 3 weeks if we will have a voice conf on Thursdays - or not

<arve> Have a nice trip, marcos

AB: meeting adjourned

<marcos> Thanks!

RRRSAgent, make minutes

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/10/30 13:05:39 $

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

WARNING: Replacing list of attendees.
Old list: Josh_Soref Art_Barstow Bryan_Sullivan +39.011.228.aaaa arve
New list: Josh_Soref Art_Barstow Bryan_Sullivan arve Claudio

Default Present: Bryan_Sullivan, Art_Barstow, +44.207.070.aabb, Josh_Soref, Claudio, arve, +47.23.69.aacc

WARNING: Replacing previous Present list. (Old list: Art, Arve, Marcos, Bryan, Josh, Claudio)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ +Mark


WARNING: Replacing previous Present list. (Old list: +Mark)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Art, Arve, Claudio, Mark, Marcos, Josh, Bryan

Present: Art Arve Claudio Mark Marcos Josh Bryan
Regrets: Thomas David Jere
Agenda: http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0201.html
Found Date: 30 Oct 2008
Guessing minutes URL: http://www.w3.org/2008/10/30-wam-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]