See also: IRC log
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 2 November 2009
AB: P+C Test Suite is first topic
MC: I made some tests pre
... at that test fest a bunch of tests were created
... I have cleaned those tests
... We now have Present Technologies people helping
... I create the test cases
... Present Technologies then checks the test cases and runs them
... So far they have tested Windows Mobile 6.5 using emulator
... Blackberry emulator
MC: the Present Technology guys
are now Invited Experts
... they have found some issues with the test cases
... they have found some bugs but nothing serious
... we haven't yet moved over the stuff from PT to CVS
AB: do you need help from the Team?
<scribe> ACTION: smith work with Marcos to get test stuff from Present Technologies moved to CVS [recorded in http://www.w3.org/2009/11/03-wam-minutes.html#action01]
<trackbot> Created ACTION-435 - Work with Marcos to get test stuff from Present Technologies moved to CVS [on Michael(tm) Smith - due 2009-11-10].
MC: we want to make the Compat
Matrix made Public
... some stuff cannot be tested because of the way we created the test suite
AB: what's an example of something that cannot be tested?
MC: there is no need for a P+C UA
to test TWI dependency
... we want the test cases to all be verified
BS: should the "can't test" test cases be put in a different test suite?
MC: no, I want these tests in the
core P+C test suite
... their coverage of test runs is getting pretty good
... also tested LG, BONDI and Wookie
AB: so the next step is to get all of this to CVS?
AB: what about the BONDI impl?
MC: it is running in an emulator
DR: we are thankful for this
... if you need anything from us, let us know
MC: there are some prereqs
... UA must support HTML4.01, CSS1, PNG, ISO-8859-1
... for example must be able to display
... and support Red, Green
... we want to implementations to support "feature:a9bb79c1
... to support the feature element
... must be able to support the "en" locale
... Eventually, we can create an Acid Test and it will have more thorough L10N tests
DR: re this featue: a9*, what does impl need?
MC: just need to return
... test suite is: http://dev.w3.org/2006/waf/widgets/test-suite/
... there are 4 testable assertions that need to be written
... when I finish there will be about 16 more tests
... results are all in an XML file
AB: is the MWTS WG still helping with P+C test suite?
MC: no, Kai is working on the
DigSig test suite
... the main goal is to be able to test interop
... I think the suite will do that
AB: any questions or comments?
MC: I need feedback from implementors
DR: the RIM stuff gets compiled
into a JAR
... so how do you test?
MC: we test via their
... it is no longer a req that a UA be able to download a package from the Web
AB: after CR#2 we would have some type of interop fest?
MC: yes and Present Technologies is willing to host it
AB: if we use the same Exit Criteria as CR#1, we need 2 impls
DR: we should have a RI by December for BONDI 1.01
s/BOND 1.01/BONDI 1.1/
<drogersuk> The BONDI Candidate Release for 1.1 (released today): http://bondi.omtp.org/1.1/CR/
<scribe> ACTION: barstow work on an interop plan for P+C spec [recorded in http://www.w3.org/2009/11/03-wam-minutes.html#action02]
<trackbot> Created ACTION-437 - Work on an interop plan for P+C spec [on Arthur Barstow - due 2009-11-10].
AB: when will the test suite be complete?
MC: next week
... want to publish test suite when we publish CR#2
MO: earlier today I sent some P+C
comments to public-webapps
... re SVG icons and width and height
MC: there is a viewport
[ Marcos displays section 7.11.1 ]
scribe: I will respond to the email after it shows up on the reflector
AB: anything else on P+C?
[ None ]
AB: input always welcome!
AB: there are comments from
Marcin and David
... and Magun had some comments
... MC wants to delete the view mode values from P+C
MC: I already did that
AB: the P+C spec was never going to tell a WUA what to do with them so this deletion is OK
MC: yes, that's right and the
mistake was to list them
... but I've fixed that
... one issue here is the default view mode in the Table of Config Defaults
... currently it says default is "floating"
... but I'm proposing it be changed to null
AB: would this change an impl?
MC: no because a WUA would just ignore it
AB: so your proposal is in CR#2
to change the default to "null"
... does anyone object to changing the default value of viewmodes to null?
... this means the impl will do-the-right-thing
[ No Objection]
RESOLUTION: the viewmode default will be changed to "null"
AB: so MH on Oct 5 wrote:
... and there have been no responses
... my take on these comments is they will affect VM-MF and/or VM-I but not P+C spec
MC: using "all" in this email is equiv to "null" i.e. leave it to the impl
AB: David had comments on VMMF on
... I think this email raises a couple of questions: do we need generic widget security guidelines and does the VMMF spec need some security considerations
[ Marcos shows some images of S60 Widgets ]
DR: we have discussed a widget
security guidelines document
... my email about VMMF talks about some scenarios to consider
AB: we can have sec
considerations per spec
... and if something doesn't fit, document it separately
DR: I'm OK with have a Sec
Consids section per spec
... I sent some info to Marcos
[ Josh and David talk about various security scenarios ... ]
DR: I think we need to document
some basic security considerations
... I have some examples in the social engr context
AB: on Tues afternoon, want to
swap the 15:30-16:30 and 16:30-17:30 slots
... we will have Widget planning at 15:30-16:30
... any objections?
[ None ]
AB: meeting adjourned
<arve> (and is the bridge up?)
<arve> I have a very young working group-member-by-extension here attempting to say hi
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
Date: 3 November 2009
<scribe> Meeting: Widgets Voice Conf
... any change requests?
[ None ]
AB: the latest ED http://dev.w3.org/2006/waf/widgets-api/
... is 19 October your latest version MC?
MC: yes, that's the latest modulo some editorial changes
AB: the email MC just sent to the list is: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0459.html
MC: the main reason we need
... is it tells how the widget operates
... the specs have some built in assumptions
... i.e. some things are assumed
<arve> do we want to _allow_ navigation?
MC: a single package could have
... each instance must have a unique storage
... this can also affect the viewport
Arve: I'm puzzled by why this isn't just a WUA problem
BS: affects what is in the package
JS: can't we just take care of this via a test
MC: must define the navigation model
Arve: that is a different
... I see the need for links to be handeld the same way
... but as for defining widget instance
... not sure we need to do that
... Opera's UA allows multiple instnaces of the same widget
MC: agree but we don't want to restrict
AB: does the text restrict it now?
MC: no, it doesn't restrict it in
... so it may be a non-issue
... but we do need a definition
Arve: how does the spec deal with referencing resources in the package?
MC: the TWI spec doesn't address
... but the URI Scheme spec does
AB: let's capture the issue
... proposed text: make sure the URI Scheme spec facilitates widget instance navigation
<Marcos> I.e., the spec needs to make it clear how to resolve relative paths
AB: is this right?
ISSUE: the URI Scheme spec needs to make it clear how to resolve relative paths
<trackbot> Created ISSUE-109 - The URI Scheme spec needs to make it clear how to resolve relative paths ; please complete additional details at http://www.w3.org/2008/webapps/track/issues/109/edit .
AB: if we look at the current defn of Widget Instance, what needs to change?
MC: we need a clear
... make it clear how instance relates to the DefaultView, Viewport and Document
JS: Window is the global
... what is ViewPort
MC: it's for styling
<arve> I would like to point out that two window instances of the same URI, in HTML5 terms, can access each other's data
<arve> we would not like that to happen with separate widget instances
JS: when a UA instantiates a
widget, by loading the default URI
... it applies the widget interface to the Window object
... For any page loaded as the top-level resource into the widgets
... if the location is same origin to the widget instance then this rule always applies
... the above is mostly right but needs some editorial changes
... some other things are also bound
<timeless_mbp> Any other widget specifications which specify bindings to objects have the opportunity to bind their Interfaces at this time according to the same rule
MC: we want to use the storage attribute that behaves the same as local storage or session storage - whichever one persists thru navigation of page to page
JK: this is localStorage then that we want
AB: so not sessionStorage but localStorage?
[ We view Web Storage spec ... http://dev.w3.org/html5/webstorage/ ]
AB: so going back to MC's email today: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0459.html
<arve> [no comment]
MC: yes, sessionStorage isn't what we need
AB: do you now have enough feedback for points 1-4?
MC: yes, I do
AB: let's move to point 5
JS: I claim this is an impl detail
MC: I agree
BS: should the spec say something about cloning?
MC: no, that would be too much detail
JS: yes I agree; we don't want to go there
Arve: may want to use "top browsing context" here as defined in HTML5
<arve> top level*
JS: yes, good idea; that could be used instead of the text I proposed earlier
<timeless_mbp> "top-level browsing context"
AB: what about point #6?
<arve> "The browsing context with no parent browsing context is the top-level browsing context of all the browsing contexts nested within it"
AB: would #6 be too restrictive?
<arve> 6 is, IMO; out of scope for TWI
<timeless_mbp> If we imagined a Widget impl modeled after Maemo 5
<timeless_mbp> which doesn't actually follow the behavior described in 6
<timeless_mbp> as it happens, no one likes this inconsistent behavior
<timeless_mbp> I could demo this unsatisfactory behavior for people ...
<timeless_mbp> It's out of scope, but basically I doubt any widget instance is likely to be foolish enough to choose not to get this right
<timeless_mbp> otoh, it's free to lose while competing in the market
MC: I agree this doesn't need to
be in the spec
... but we need to make sure we don't explicitly preclude it
... browsing context is a concept
... and the WindowProxy is the thing that can then be operated upon
JS: we may want to bind on WindowProxy but I'm not sure
[ We look at Browsing Context in HTML5 http://www.w3.org/html/wg/html5/ ]
MC: we may be able to use DOM L2
... I need to read this part of HTML5
<arve> Again, if the widget interface spec needs to reference DOM L2, it's a separate spec
MC: need to understand all of the relationships
<arve> (It actually is, if we reference CSS-anything as well)
Arve: if need to reference CSS2 or DOML2 View, need a new spec
MC: yes, true
... we may want to stay silent and just focus on the storage
<annevk> DOM2 View will be obsoleted fwiw
<annevk> (its concept of views, anyway)
<Marcos> annevk: what supersedes it?
<annevk> CSSOM View
MC: view and default view are defined by HTML5
<annevk> (HTML5 will remove its concept of views too, accordingly)
<scribe> ACTION: marcos work with Hixie and Anne on a definition of Widget Instance [recorded in http://www.w3.org/2009/11/03-wam-minutes.html#action03]
<trackbot> Created ACTION-438 - Work with Hixie and Anne on a definition of Widget Instance [on Marcos Caceres - due 2009-11-10].
MC: I get questions about why some of the metadata in the config file is not an attribute of the Widget object
<arve> Baby cried
BS: how about just adding all of them?
AB: and just making them DOMStrings
<arve> But, read the context, and would not object
AB: propose add license and short
name to the Widget object as new attributes
... any objections?
RESOLUTION: will add license and short name to the Widget object as new attributes
BS: what about icons?
MC: I don't want to add them
until we have a proper API
... the icons are complicated
AB: Marcin's comment #1 Sep 23:
... Marcin's comment #2 Sep 23: http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1205.html
MC: those two threads are related to VMMF and VMI specs
AB: so not TWI?
MC: correct, not TWI
AB: Dom did some TWI test work: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0405.html
MC: these tests dont' really help
to verify the spec
... not clear if I'll be able to use what he has done
... but I won't know for sure until I do a deep dive on it
AB: anything else about TWI?
MC: no, I think we've covered the
... after I have defined Instance and its relationship to origin and URI spec, we'll be done
... I need to talk to Robin about it
AB: so the status is that MC
needs to do some work before the spec will be ready for a new
... It will probably take me about two weeks before the spec is ready for review
... anything else on TWI for today?
<arve> That was the session from 11:00 to 13:00?
<arve> Just said: Have fun, resolve all issues.
<scribe> Chair: Art
Date: 3 November 2009
[ MC explains the 1 package 3 instances scenario to Hixie ... ]
MC: each instance has its own
... Zip has multiple HTML files
... want to use the "right" terminology from HTML5
IH: the circles/instances are top-level browsing context
MC: are these TLBC's WindowProxy or something else
IH: any BC has a WindowProxy
... a session history is bound to a BC
MC: the BC is an abstract concept
IH: the BC is accessible from
script via Window
... can only compare WindowProxy
... a BC has a session history
... do these instances have back and forward?
MC: yes they do
IH: session history is a list of
docs but has other things
... two entries in sess history
... each doc in the history has a Window object
JS: we want to add some properties to Window or WindowProxy
MC: origin retention is important
IH: origin is an opaque identifier derived from the UUID
JS: we are just saying its an opaque id
IH: any resources loaded from the instance will have the same origin
MC: so, we just need to talk about TLBC
JS: and the properties are off the Window object
IH: take a look at Window Modal IDL
<Hixie> this is the WindowModal example i was talking about: http://www.whatwg.org/specs/web-apps/current-work/#windowmodal
MC: next problem is
... we want to reuse existing spec if we can
IH: want to create an @viewport rule
MC: we need viewport landscape, portrait
IH: CSS already defines viewport
MC: we need to define viewport rule to work for web pages and not just widgets
[ Josh demos orientation changes with mobile device ]
IH: you should probably talk to the CSS WG
MC: we will say widget prefs will be localStorage
<timeless> anyone here?
<timeless> we'll be there in 5mins
AB: widgets pub status is: http://www.w3.org/2008/webapps/wiki/PubStatus#Widgets_Specifications
BS: I will upload an image of MC's diagram from earlier today
MC: I'll add it to the TWI spec
<scribe> ACTION: barstow determine a plan for P+C CR#2 and beyond [recorded in http://www.w3.org/2009/11/03-wam-minutes.html#action04]
<trackbot> Created ACTION-443 - Determine a plan for P+C CR#2 and beyond [on Arthur Barstow - due 2009-11-11].
MC: there are too many issues with adding license to the Widget object
AB: any objections to keeping it out?
<scribe> ACTION: benoit submit a proposal for adding license to the Widget object [recorded in http://www.w3.org/2009/11/03-wam-minutes.html#action05]
<trackbot> Created ACTION-444 - Submit a proposal for adding license to the Widget object [on Benoit Suzanne - due 2009-11-11].
<scribe> ACTION: marcos to remove license from the ED of the P+C [recorded in http://www.w3.org/2009/11/03-wam-minutes.html#action06]
<trackbot> Created ACTION-445 - Remove license from the ED of the P+C [on Marcos Caceres - due 2009-11-11].
<scribe> ACTION: barstow send a request for pre-LC comments for the TWI spec [recorded in http://www.w3.org/2009/11/03-wam-minutes.html#action07]
<trackbot> Created ACTION-446 - Send a request for pre-LC comments for the TWI spec [on Arthur Barstow - due 2009-11-11].
<scribe> ACTION: barstow send a reminder to review URI scheme spec [recorded in http://www.w3.org/2009/11/03-wam-minutes.html#action08]
<trackbot> Created ACTION-447 - Send a reminder to review URI scheme spec [on Arthur Barstow - due 2009-11-11].
MC: my prios are: P+C test suite,
... need to spend time on test suite for DigSig
<scribe> ACTION: barstow review DigSig test suite; get comments from Frederick [recorded in http://www.w3.org/2009/11/03-wam-minutes.html#action09]
<trackbot> Created ACTION-448 - Review DigSig test suite; get comments from Frederick [on Arthur Barstow - due 2009-11-11].
MC: Opera opposes URI and WARP
going to CR without a prior test suite
... I think these two will be relatively easy to test
... will need to discuss with Robin
... may need to get some help from Consortium to set up a persistent test domain
... but that will be needed by CORS, XHR, etc.
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) FAILED: s/BOND 1.01/BONDI 1.1/ Found Scribe: Art Found ScribeNick: ArtB Found Scribe: Art Found Scribe: Art Found ScribeNick: ArtB WARNING: Dash separator lines found. If you intended them to mark the start of a new topic, you need the -dashTopics option. For example: <Philippe> --- <Philippe> Review of Action Items Default Present: arve, Widgets WARNING: Replacing previous Present list. (Old list: Art, Josh, Benoit, David, Marcos, Magnus) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ Art, Josh, Benoit, Marcos, Jere, Arve, Magnus, Jean-Pierre Present: Art Josh Benoit Marcos Jere Arve Magnus Jean-Pierre Hixie Agenda: http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Agenda_Items Found Date: 02 Nov 2009 Guessing minutes URL: http://www.w3.org/2009/11/03-wam-minutes.html People with action items: barstow benoit marcos smith with work[End of scribe.perl diagnostic output]