See also: IRC log
<ArtB> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 30 July 2009
<Marcos> argh, there is a guy with vacuum cleaner outside my office :(
AB: agenda posted on 29 July ( http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0426.html ). Any change requests?
[ None ]
AB: No call on August 6; next call is August 13. Any other short announcements?
[ None ]
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
... 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
... 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
... 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
... Mike, can you manage a CfC for A+E LCWD next week?
MS: no, that isn't likely to
... because of the vacation period this isn't a good time to get comments
... 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?
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/
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
... 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
... 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]
AB: the Window Modes spec (
) 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
AB: anything else on WM spec?
[ No ]
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
... 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
... 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
... 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
MC: after I complete this task, I will create a list of changes
AB: any other comments about P+C testing?
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
... 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
<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
... 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/remove att/removed att/ Succeeded: s/then/than/ Found ScribeNick: ArtB Found Scribe: Art Found ScribeNick: timeless_mbp Found Scribe: timeless Scribes: Art, timeless ScribeNicks: ArtB, timeless_mbp Present: Art Marcos David Mohammed Marcin Josh Mike AndyB Regrets: Frederick Robin Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0426.html Found Date: 30 Jul 2009 Guessing minutes URL: http://www.w3.org/2009/07/30-wam-minutes.html People with action items: barstow[End of scribe.perl diagnostic output]