See also: IRC log
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
<darobin> ArtB, thanks :) we have quite a few more in the pipeline....
AB: yesterday I posted the agenda
(
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0979.html
). Any change requests?
... re Widgets Dig Sig, Frederick sent regrets for today but
Thomas can join us so we'll make that the first spec.
AB: any short announcements?
TLR: we are looking into a
workshop re privacy and APIs
... specifically, device APIs
... e.g. Geolocation
... TAG has done some related discussing
... CfP could be available in a week or two
... If anyone is interested in helping, ping me offline
MC: sounds interesting; I'd like to participate
AB: this sounds good; expect Nokia to participate
AB: earlier this week, Frederick
announced a bug in the Widget DigSig spec related to C14N (
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0953.html
). Yesterday he submitted a modified proposed resolution (
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0980.html
).
... the main issue is the spec isn't clear which C14N algorithm
to use i.e. 1.0 or 1.1 and the proposal is to make it explicit:
use 1.1.
... the modified proposal includes 3 normative changes and a
couple of non-normative changes.
... for today, mainly want to see if the issue(s) and proposed
resolution are clear.
TLR: there may be a bug in the
bug
... in the proposed resol re section 7.2
... some of that text is not correct
... I will follow-up today
AB: thank you
BS: does this mean that tools that sign will need to change?
TR: the change should be fairly
minor
... the change to the markup is just explicitly adding the
algorithm to use
... If a change is needed, that means you are using 1.0 for the
object and 1.1 for everything else
... Changes should be minor, depends on what the impl does
BS: so if sign a widget with current tool and then test with updated tool?
TR: the old signatures are not
likely to be conformant with the spec as changed
... if some type of generic tool was used, it may work
BS: having those details would be
helpful
... especially for those that have already deployed based on
the current spec
... Will need to resign?
TR: if a widget is signed
according to old spec and uses 1.0
... then want to know if 1.1 verifier will throw an error or
not
BS: need to clear answer to these deployement questions
TR: read Frederick's email
... there is should level support for 1.0
BS: OK; will read it
TR: I will follow-up in email today
AB: let's try to respond to FH
and TLR's emails by April 8
... want to know by then if this is going to cause major
problems or not
AB: the last thread on Marcos' new <span> and dir model is ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0936.html ). Marcos, what's the status?
MC: I think we might be done
<scribe> ... pending one note
UNKNOWN_SPEAKER: i.e. the
security precautions
... unicode and URIs
AB: have you received any responses to your revised proposal?
MC: they said they will reivew at next voice conf
AB: so we'll need to wait for
them to respond
... re next steps with this spec, I'm not sure we can go
straight to PR
MC: we can argue we haven't really changed functionality
RB: I think it is a small enough change we can go to PR
MC: I created some tests
... but we need some way to run the tests
AB: what % of the dir and span tests are completed?
MC: I just have a skeleton; haven't created actual widgets
RB: re how to run the tests
... this is no diff from other aspects of the config file
... i.e. they don't show in the UA's UI
... just use dumps or something like that
AB: not sure you need to create the same quality of tests we have for our Mandatory tests
MC: yes, just need to show the parsing is done correctly
AB: Steven, do you think Team will support going to PR?
SP: yes, as long as you've got the tests, that should be good enough
MC: it will be very diff for us
to show a UA that displays the info
... we'll have to take it on an implementor's word that they've
"done it"
... our test reports are based on a core parsing engine that
doesn't have any UI
SP: depends on the exit
criteria
... CR should prove the spec is implementable
... need to show they are implemented somewhere and
interoperable
MC: thanks for the clarification
AB: yes, that was helpful
... the PoA is: get closure with I18N WG re the latest changes
Marcos proposed and then to proceed to PR
... any disagreements?
... or any concerns?
[ No ]
<darobin> +1
AB: Issue-116 is "Need to flesh out the security considerations for the openURL method in the Widget Interface spec" ( http://www.w3.org/2008/webapps/track/issues/116 ). Marcos, what's the status on the proposed text?
MC: we are still sorting it
out
... I don't have a new proposal
... but hope to have something soon
AB: is there something the rest of us can provide to help?
MC: I don't think it will change
any normative text
... we are blocked on implementations
... don't think we need to worry about it
AB: the TWI Implementation Report ( http://dev.w3.org/2006/waf/widgets-api/imp-report/ ) indicates Opera passes 100% of the tests. We need another implementation to pass 100% of the tests to exit Candidate. Can anyone provide some additional implementation data?
RB: I do plan to make an update within two weeks
AB: for widgeon?
RB: for a new approach for widgeon
AB: does anyone else have impl data they can share?
AB: what is the status of the WARP test suite ( http://dev.w3.org/cvsweb/2006/waf/widgets-access/test-suite/ )?
RB: nothing recent from me
MC: nothing recent from me
either
... the spec has been marked-up for testing
... just need the tests
... I'd like to move this to CR as quickly as possible
... and I don't think we need a test suite before publishing
the CR
RB: I'm fine with that as well
AB: any other comments about going to CR now?
[ No ]
<scribe> ACTION: barstow add proposal to move WARP spec to CR to April 8 agenda [recorded in http://www.w3.org/2010/04/01-wam-minutes.html#action01]
<trackbot> Created ACTION-513 - Add proposal to move WARP spec to CR to April 8 agenda [on Arthur Barstow - due 2010-04-08].
AB: before I can ping IETF on the status of our scheme registration, Robin needs to respond to Julian re ( http://www.w3.org/2008/webapps/track/actions/510 ). Robin, what's the status of this action?
RB: I still have some edits to
make
... then I will respond
... they have a 4-week review period
... think that ends next week
... I intend to reply to original posters
... and then to uri-review to determine the status
... anyone know about implementation?
MC: not sure about our
status
... could have been based on an old spec
RB: widgeon implements it
AB: we had some discussion about the authority
AB: during our last meeting we
had a short discussion re comments from CSS WG re the VMMF spec
( http://www.w3.org/2010/03/18-wam-minutes.html#item06
) but without Robin, we didn't dive too deep.
... Comments from CSSWG:
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0804.html
... Comments from Daniel Glazman:
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0800.html
... Comments from Brad Kemper:
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0803.html
... Height and width attribute (raised by Marcos):
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0847.html
... I'd first like to talk about the scope question e.g. keep
its scope limited or expand it. Daniel said "why is this
restricted to widgets"
RB: I agree with DG that it shouldn't be
MC: I agree to but what does that mean work wise
RB: I think it just means removing any refs to "widgets"
<kenneth> me too, btw I have additional comments: http://www.mail-archive.com/public-webapps@w3.org/msg08111.html
RB: it could affect the test suite
<Marcos> Kenneth, will you join the call?
<kenneth> Marcos, can I?
<Marcos> certainly is
<darobin> kenneth: certainly
RB: I can respond to all of the comments
AB: there are a couple I'd like to discuss today
<kenneth> ok could anyone give me info on how to call? Then I will find a room with wifi
MC: re width and height
RB: not sure it needs to be in MF spec
MC: yes, I kinda' see what you mean
RB: in P&C we say they are indications
<kenneth> ok I will try!
MC: P&C says given width and height, it says what UA does is dependent on the view mode
<Marcos> "Authoring Guidelines: It is optional for authors to use the width attribute with a widget element. This value is only applicable to particular view modes, meaning that for certain view modes this value is ignored. The view modes that honor the value of the height attribute are defined in the [Widgets-Views] specification. "
MC: but that text is non-normative
AB: ah, I see
RB: we could just drop that last sentence
AB: would that be OK Marcos?
MC: I think that would be
OK
... don't think it will cause interop probs
AB: feels like being silent here is the right approach
MC: OK, I will remove those two sentences (once for width and once for height)
AB: ok, good
... the need for the "all" value
RB: I think it makes sense to
have a catch-all
... an API could return all
... and it tends to be consistent with some of the other
MQs
... I'm not married to it
... Kinda' like the inherit value
KC: but isn't it equiv to not having anything
RB: I just copied it from MQs stuff
KC: if have any new view modes in the feature, it would cause probs
RB: if can match on all, then know the UA supports view-mode
KC: could just ask for view-mode then
MC: on the config side, leaving
view mode out equates to all
... which equates to view mode
<Marcos> <widget viewmodes="">
AB: so there would be some
consistency for not having it?
... would anyone object to it being removed?
RB: I would not
KC: could clarify it is always true if it is a widget
RB: but we don't want to tie it to widget
AB: proposed RESOLUTION: the "all" value will be removed from the VM-MF spec
<darobin> +1
AB: any objection?
RESOLUTION: the "all" value will be removed from the VM-MF spec
AB: the "hidden" value DG proposed
RB: I can see some value
... e.g. stopping a CSS animation
AB: without more compelling use case and resources to drive it, not sure about it
KC: may want to stop CSS animations on mobile devices e.g. to save battery
JS: is that a UA problem or author issue?
KC: may want to give author
control
... some of the names are confusing
RB: I'm ok with windowed instead of application
MC: I'm OK with that but we've already implemented "app"
RB: I don't want to bikeshed on names
AB: agree
MC: yes, but we do have
implementations
... we don't want to invalidate them
RB: they should be use -X
KC: in webkit, using -webkit
RB: MC, can you get us some data
<Marcos> http://widget.vodafone.com/dev/
RB: need to be careful here
AB: without substantial reasons to change, not sure we should change them
KC: need to make them more general
RB: the entire spec is more general
KC: should be relatively easy to support different names
RB: I'd like to get implementors debate this on the mail list
AB: any other comments on VM-MF for today?
AB: during the discussion about the pre-LC version of the VMMF spec, questions were asked about the relationship between VM-I spec and CSSOM specs ( http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html ) and ( http://dev.w3.org/csswg/cssom-view/ ) via the thread ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0933.html )
KC: need a way to change the View
Mode from JavaScript
... everything else is already in CSSOM
AB: are you saying VM-I spec isn't really needed
KC: just need the view mode change stuff moved into CSSOM
MC: it would be ideal if CSSOM Editor and Kennett could work today and make sure our use cases get into the CSSOM spec
KC: not sure how that would work in practice
MC: we're happy to help
<scribe> ACTION: barstow work with Kenneth on a plan to address VM-I use cases and reqs via the CSSOM spec [recorded in http://www.w3.org/2010/04/01-wam-minutes.html#action02]
<trackbot> Created ACTION-514 - Work with Kenneth on a plan to address VM-I use cases and reqs via the CSSOM spec [on Arthur Barstow - due 2010-04-08].
AB: does anyone have any other
discussion points for today?
... next meeting will April 8
MC: will charter be renewed by then?
AB: no
<Marcos> "When the attribute is missing, or is left empty, it implies that the author allows the user agent to select and appropriate viewmode for the widget."
<timeless_mbp> … it indicates the author has not requested a specific viewmode
<timeless_mbp> ?
AB: meeting adjourned
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/DR/RB/ Found Scribe: Art Found ScribeNick: ArtB Present: Art Thomas Steven Robin Marcos bryan_sullivan Josh Kenneth Regrets: Frederick Marcin Agenda: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0979.html Got date from IRC log name: 01 Apr 2010 Guessing minutes URL: http://www.w3.org/2010/04/01-wam-minutes.html People with action items: add barstow proposal[End of scribe.perl diagnostic output]