Widgets Voice Conference -- 30 Jul 2009

<ArtB> ScribeNick: ArtB

<scribe> Scribe: Art

Date: 30 July 2009

<Marcos> argh, there is a guy with vacuum cleaner outside my office :(

Review and tweak agenda

AB: agenda posted on 29 July ( http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0426.html ). Any change requests?

[ None ]

Announcements

AB: No call on August 6; next call is August 13. Any other short announcements?

[ None ]

A&E spec

AB: The A&E spec should be close to being ready for a LCWD publication ( http://dev.w3.org/2006/waf/widgets-api/ ). There were two related threads recently.
... first is "localStorage and preferences" ( http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0284.html ). Any follow-ups on this thread?
... Marcos, where do we stand on this thread?

MC: we decided to keep localStorage
... we will not try to combine them

AB: any other comments on this thread?

MC: no; conclusion was not to make a change

AB: on July 9 Robin responded ( http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0156.html ) to the A&E ToDo list with some proposals. Two items appear to be open: 1) need FPWD of Window Modes spec; 2) showNotification method

MC: Robin and I spent a lot of time on the A+E spec last week
... I haven't uploaded the latest changes yet
... among the recent changes ....
... added usage examples
... removed attributes definitions and point to the related defns in the P+C spec
... removed window mode attribute
... it will be defined in the Window Modes spec
... the A+E spec now has no dependencies on the WM spec

AB: that's good

MC: so we can now finish A+E ASAP
... we specified showNotification method
... it is based on some old text from HTML5
... it was originally in HTML5 but it was removed from it because of lack of interest by implementors
... but our use case is a bit different
... we have only taken the bits we need

AB: ok; good idea

MC: I made the storage area a "product" wrt conformance
... but our storage area is different than what is defined in Web Storage spec
... because some of our key value pairs are read only
... e.g. if they are from the config file

AB: any other major changes?

MC: no; I think I've covered them all
... we are close to having this finished
... mostly just Editorial changes
... some links need to be added
... may need to put a dependency on HTML5 defitions but not sure

AB: what is the ETA for us to have a doc ready to approve or not a LCWD?

MC: 1 week

AB: we could use the CfC process
... Mike, can you manage a CfC for A+E LCWD next week?

MS: no, that isn't likely to happen
... because of the vacation period this isn't a good time to get comments

AB: understood
... Marcos, by Aug 6 can you send an email to the list that gives the group 1 week to send comments on the proposed LCWD?
... and then on Aug 13 we can give a Go/NoGo on A+E LCWD

MC: yes; will do

AB: last comments on A+E?

<Marcos> http://www.w3.org/TR/widgets/

AB: oh, there is definitely something broken there

<timeless_mbp> Zakim: aacc is abraun

AB: with the P+C link ala .../TR/widgets/

<Marcos> MikeSmith: http://www.w3.org/TR/2009/CR-widgets-20090723/

WARP spec

AB: during the July 9 VC we agreed to publish a LCWD of WARP ( http://dev.w3.org/2006/waf/widgets-access/ ). However, by the time it was pub ready, I was offline for vacation. Since then, Marcin submitted two related emails.
... first is "@required attribute on <access> element" ( http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0290.html ). Any comments?

MH: need to think about <access> in the context of DAP WG
... and policy formats
... want access, especially network access, to be handled consistently
... feature is something we can control; Bryan provided some use cases for controlling network access
... required attr on <access> was proposed by Bryan
... it could be specified outside of the W3C
... but getting consensus in W3C would be best
... want DAP WG to define access policy
... During London f2f meeting we didn't thoroughly discuss this issue, IMO.

MC: I still don't see a good use case for this
... if operators want to restrict some net access then so be it
... but that won't make sense in some cases
... not clear adding this attr helps
... don't think authors should be bothered with this

MH: don't want to mandate operator define the security policy
... but may have a use case where a user defines the policy
... I understand there are different usage scenarios

AB: I'd like to propose we publish the WARP LCWD as is with a long comment period, say until mid-Sept
... this would allow DAP people, still joining this new WG, some extra time
... as well as vacationers extra time
... and then if Marcin, Bryan or anyone else has serious concerns about the model as specified, they can submit comments during the LC comment period
... I don't want to continue to rehash a decision we already made
... any objections to that proposal?

MH: no objection

MC: no objection

RESOLUTION: to publish LCWD of WARP as is

<scribe> ACTION: barstow submit the publication request for WARP LCWD today [recorded in http://www.w3.org/2009/07/30-wam-minutes.html#action01]

Window Modes spec

AB: the Window Modes spec ( http://dev.w3.org/cvsweb/2006/waf/widgets-wm/ ) hasn't been published yet. Robin submitted a ToDo of things that need to be done before the first publication (http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0218.html ) [Thanks Robin!]. We can take some comments now but it would be better to submit your comments to public-webapps.
... we no longer have a dependency of A+E on this spec and that's good
... but the list of items to be done is quite long
... any volunteers to help Robin on this?

MH: yes, as a co-Editor of this spec I pinged Robin
... but didn't get a response yet

AB: how can I help

MH: if you were to follow-up with Robin, that would be good
... some practical editing questions really

MC: just go ahead and edit the spec

MH: ok; that's fine

AB: is there a risk of overwritting each other changes?

MC: not now since the spec is basically empty

AB: so Marcin, either make a change directly or make a proposal on the list

MH: ok

AB: anything else on WM spec?

[ No ]

P&C spec

AB: the P&C spec ( http://dev.w3.org/2006/waf/widgets/ ) is now in Candidate state and that means we have to create the test suite.
... Marcos proposed ( http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0310.html ) a high-level testing strategy. Any comments on this proposal?

DR: how does this tie into the widget testing workshop?

MC: I'm not sure if the output from the WS will be directly useable
... need to create the template
... and then the test cases themselves
... also need to create the list of assertions
... perhaps the WS will be used to create more "acid tests" then test case for the spec

DR: this begs the question: why have the WS?

MC: I am very concerned about the quality of the test cases
... only want high quality test cases in the spec's test suite

AB: any other comments on MC's proposal?

<drogersuk> I am in agreement with Marcos. So the question is, is this an action on Dom?

AB: it looks like a good proposal to me

MC: Kai and I will create the template
... and a "how to write a test" proposal
... and then send that to Dom for approval
... I won't be able to attend the WS
... if anyone wants to help Kai and I, that would be great

<drogersuk> We need to encourage the right people to come along if you have concerns about the quality too

MC: I think we can start generating tests

<drogersuk> I will circulate to our compliance lists, I suspect there is already some cross-over

MC: Opera may submit their test suite
... hope the test suite can be completed before the WS
... and then any test case created at the WS could potentially be added

AB: a general question is how to manage spec changes during the CR phase
... naturally, we must be careful about major changes that would affect an implementation base on the 23 July Candidate
... today in IRC, Marcos mentioned a "bug" in the CR that should be fixed

<drogersuk> it would be great if you could put that on the public mailing list

AB: we need to document all bugs; we need to notify impementors about bugs, etc.

MH: I found a bug; but not clear how to address it

AB: so the straman proposal when a bug in the CR is found, is to send an email to public-webapps with a subject like
... [widgets] BUG ALERT for P+C spec: <description>

<marcin> it is not essentially a "bug", but a "feature' of the spec. We just need to clarify whether it operates on octets or characters

AB: want to make sure the Public knows when we have identified a bug

MH: yes, agree we need to document all bugs

AB: Marcos agreed earlier today to submit an email to the list that describes a bug he found

MC: we could publish an errata

AB: my understanding is the W3C's erratta process only applies to RECs
... perhaps Mike can verify

MS: yes that's correct, errata are for RECs, not for WDs or CRs

<Marcos> Test suite edition of the P&C: http://dev.w3.org/2006/waf/widgets/Overview_TSE.html

MC: regarding testable assertions, I created a "Test Suite Edition" of the P+C spec
... it removes some redundancy
... and removes assertions that cannot be tested
... it identifies all of the testable assertions
... In "orange", you should be Testable Assertion and some Identifier
... [ if using a "modern" browser ]
... We will then use Dom's assertion extractor to create the assertion list
... This work has resulted in identifying some redundancies that can removed from the spec as Editorial changes
... This will give us a much better spec

AB: this is good work Marcos; I like this approach!

MC: I want to use this approach for the other widgets specs too
... but will need to get agreement from the other Editors

<drogersuk> +1

MC: after I complete this task, I will create a list of changes

AB: any other comments about P+C testing?

Widget URI spec

AB: Marcin submitted two emails for the URI spec ( http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ ).
... 1st is "Internationalization, widget IRI?" ( http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0339.html ). There is also some followup on the public-uri mail list ( http://lists.w3.org/Archives/Public/public-iri/2009Jul/0017.html ). Any comments?

MH: I submitted some comments for the IRI draft
... 3987 RFC
... We should not expect a resolution from that group soon
... Need to make sure URI to IRI mapping in P+C is clear
... I think we can mandate a URI to IRI conversion
... We should also talk to I18N Core WG

<Marcos> "For interoperability, manipulations of Zip relative paths MUST be performed on the string obtained by decoding the file name field using the appropriate encoding, and not on the bytes initially stored in the archive. For the sake of comparison and matching, it is RECOMMENDED that a user agent treat all Zip-relative paths as [UTF-8]."

MC: we have some text in the spec [ see above ]

<Marcos> "and not on the bytes initially stored in the archive"

<marcin> ok, this is ok for zip-rel-path

<marcin> we have the issue with IRIs in config.xml

MC: this is an interop hurdle for widgets

MH: two issues: 1. zip-rel-path grammar change needed

MC: I think we should talk about this offline
... not clear if it is a bug or not

[ some discussion between MC and MH ... ]

MH: need to consider the text editor the author uses to create the config.xml file

MC: I think there is an authoring requirement or guideline that needs to be added
... but it won't affect the WUA

MH: I agree we can take this offline

AB: anything else on Widget URI spec for today?
... one concern I have is raising the level of visibility of this spec

<timeless_mbp> ScribeNick: timeless_mbp

<scribe> Scribe: timeless

AB: I think we're actually done with the widget uri discussion

AOB

<drogersuk> Version 1.01 of BONDI is now available at http://bondi.omtp.org . It contains some minor edits and errata.

AB: the next meeting is August 13
... meeting adjourned

- DRAFT -

Widgets Voice Conference

30 Jul 2009

Attendees

Contents