Widgets Voice Conf -- 08 Oct 2009

<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

Date: 8 October 2009

Review and tweak agenda

AB: draft agenda submitted Oct 7 ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0073.html ). Any change requests?

[ No ]

Announcements

AB: does anyone have any short announcements?
... see member-webapps for TPAC announcements

MC: I noticed RIM is supporting the W3C widgets spec

AB: yes, I saw that too

<scribe> ACTION: barstow contact RIM and ask them to join WebApps [recorded in http://www.w3.org/2009/10/08-wam-minutes.html#action01]

<trackbot> Created ACTION-412 - Contact RIM and ask them to join WebApps [on Arthur Barstow - due 2009-10-15].

P+C: Issue #88

AB: Issue #88 ( http://www.w3.org/2008/webapps/track/issues/88 ) was Raised several months ago. If we are going to address this, the spec must be changed before the next LCWD is published.
... Marcos raised this in May
... we should record a group's decision on this for v1

<drogersuk> Hi, yes on mute

<Marcos> +q

<drogersuk> Horrendous feedback from someone

JK: not much a widget can do because there is no event re locale change
... if there was an event, something could be done
... not clear how prefs are connected
... should be locale independent

MC: agree it is a no issue

Bryan: agree with what has been said
... thus I say don't do anything

<drogersuk> I agree with Bryan's comment

AB: any disagreements with what has been said so far?

MC: I agree there is no relationship between locale and prefs

AB: my recommendation is we change the state to Closed since we aren't going to do anything about it
... any disagreements with that recommendation?

[ None ]

RESOLUTION: Issue #88 is closed

P&C: Issue #93: deprecated, grandfathered, and redundant tags should be skipped

AB: Issue #93 ( http://www.w3.org/2008/webapps/track/issues/93 ) was raised by Opera during the CR phase. Has this been fixed in the TSE spec?

MC: yes I believe this has been addressed

AB: your use of "believe" here makes me feel a bit uncomfortable

<scribe> ACTION: caceres send a status report on Issue #93 [recorded in http://www.w3.org/2009/10/08-wam-minutes.html#action02]

<trackbot> Created ACTION-413 - Send a status report on Issue #93 [on Marcos Caceres - due 2009-10-15].

AB: if you think it is closed, please include a proposal to close it, Marcos

MC: OK

P&C: its:dir

AB: the its:dir feature is marked "At Risk" in CR#1. Going forward the options include: remove before LC#3; remove before CR#2; move it to a new spec; keep it in the spec. What do people think we should do with this feature?

MC: I think we should leave the feature and remove the at risk
... that is, make it an optional part of the spec

AB: any other comments?

MH: I'm OK with making it optional

JK: I'm kinda' indifferent
... not much of a diff between leaving it optional and removing

<fhirsch> would leaving it in require interop and will that be achieved?

MC: think it will be needed at some point
... if we leave it in, requires use of another name space
... think we should define these two attrs in our own namespace

AB: not sure I agree with that later recommendation
... summary: people want to keep it in
... does anyone object to keeping it in?

[ No ]

RESOLUTION: the its:dir feature will remain in the P+C spec

MC: want to also discuss removing the At Risk Feature

AB: that's a separate discussion that I would like more time for the group to consider

MC: I'm OK with more time but personally I want to remove At Risk for this feature

<scribe> ACTION: barstow start some type of CfC on whether or not the the its:dir should be labeled as Feature At Risk [recorded in http://www.w3.org/2009/10/08-wam-minutes.html#action03]

<trackbot> Created ACTION-414 - Start some type of CfC on whether or not the the its:dir should be labeled as Feature At Risk [on Arthur Barstow - due 2009-10-15].

FH: I think what MC says makes sense but wonder if we create a problem during interop

MC: no because we will not test Optional parts of the spec

FH: OK; thanks

P&C: Need normative statement of Mandatory vs. Optional attributes?

AB: apparently, I am the only member of the group that thinks the P&C spec should include a normative statement about attributes being Required or Optional ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0072.html ). This information was included in CR#1 but is not included in the TSE.
... Marcos indicated in ( http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1476.html ) that he moved the Conformance Checker requirements to the new PC-CC spec ( http://dev.w3.org/2006/waf/widgets-pc-cc/Overview.src.html ). That email did not say anything about removing normative authoring requirements from the spec.
... Marcos thinks this was the right thing to do; anyone else?

MH: I think the spec should say whether attrs are optional or not

<Marcos> +q

JK: the relax NG schema, is it normative?
... if yes, it should state what is required

MC: none of the attributes are required
... the schema can't help here
... I think Step 7 is clear enough
... the document doesn't include author requirements
... that is the role of the ConfChecker
... the spec is only about the user agent

AB: this is not consistent with the WARP spec which explicitly states whether the <access> element's attributes are Required or Optional
... this is not consistent with the Updates spec which explicitly states whether the <update> element's attributes are Required or Optional

<JereK> maybe need both normative schema and processing model?

AB: does anyone else have any comments on this topic?

<Benoit> + Benoit

<Marcos> The rationale for removing if something is required to be used by an author is that it does not matter to the user agent. The user agent just processes files, it does not tell the author anything meaningful.

MC: if a CC is included, these concerns about authoring will be addressed
... it could use the schema and correct authoring errors

<JereK> HTML with errors in browser is different use case than this

Bryan: the constraints in limited devices are clear

<JereK> I don't want validation in device either

Bryan: can't have comprehensive conf checking for example
... when processing does occur, the ua should inform user if there are errors
... are you saying ua should do no validation

MC: want to separate concerns
... ua may or may not inform user
... can add CC reqs on top or not

AB: I object to this spec no longer addressing the requirements for the Author/Creator of a config document. I would prefer this be fixed before we publish the next LCWD but if people feel there is some urgency to publish a new LCWD, I can wait and submit my formal objection during the next LC review period.
... is there a preference?

SP: last call implies all issues are dealt with
... so group should address the issue before new LC is published

MC: I still am confused as to how these things are expressed
... not sure what to say

AB: my concern could be addressed by stating something like the following in Section 7 "From an authoring perspective, all attributes are optional unless explicitly stated as required."
... let's continue on the mail list

DR: does this mean we need to deal with this now?

Benoit: yes, I think so

AB: yes, David that's what I meant by "continue on the mail list"

DR: OK; so we need to agree with this now

AB: by "now" we mean before next LC not "during this voice conf"

MC: I understand what Art wants
... we could say something about the minimal config doc
... agree to continue on the mail list

Benoit: so you are OK with what Art wants to add?

MC: yes

is P&C-CC ED ready for FPWD?

AB: last week we said that today we would discuss whether the P&C-CC ED ( http://dev.w3.org/2006/waf/widgets-pc-cc/Overview.src.html ) was ready for FPWD.
... it's missing too much of the boilerplate plus I need to review it in the context of what holes it may have created in the P&C spec.
... we will poll on this question today
... anything else on this new doc for today?
... I strongly encourage to look at both the TSE and this P+C-CC spec
... I think we need to advance these two simultaneously

<drogersuk> Some notes to add to minutes above: (just above my q+) My original question said that art stated that he would object if we didn't solve this before next LC so I responded by saying that we therefore need to deal with this issue before LC - happy to continue on mailing list.

TWI: status of LC comments?

AB: TWI Editors, what is the status of the TWI LC comment processing ( http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-apis-20090818/

MC: the td is not up to date
... the spec itself still has some outstanding emails

TWI: spec testability

AB: is the TWI spec testable as is? It would be good if we can learn from our P&C test suite and minimize the number of LCWDs that need to be published.
... does this spec need a huge amount of work?

<Marcos> http://dev.w3.org/2006/waf/widgets-api/

MC: no; it already uses the test case markup syntax
... thus it should be relatively easy to extract testable assertions
... and hence to create test cases

AB: OK; good

MC: probably need to check the assertions to make sure they all have ids
... also have some test infra in place and that should help

TWI: LCWD#2 publication plans

AB: when will it be ready for us to do a pre-LC scrub?

MC: I'm held back because P+C is higher prio

AB: is there something you need from the rest of us re the TWI spec?

MC: not really
... I still have a fair amount of work on P+C
... including media type
... Arve isn't available now and that doesn't help

WARP: is "uri" attribute name clear enough?

AB: Scott Wilson ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0019.html ) and Phil Archer ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0042.html ) have given their opinion. Is the new information compelling enough to change the name of the "uri" attribute?

MH: the comments are more about the contents of the attr rather than the name
... need to think about the proposals e.g. use regex

WARP: is semantics too constrained?

AB: Steve Jolly says ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0011.html ) WARP's model is too constrained for some of BBC's use cases. Do people agree and if so, is this something we want to address in v1.0?

MH: I think we should address this in v1
... if we go to v2 with this req, could have interop prob with v1

<drogersuk> just one minute to read Steve's email

AB: any other comments on this?
... David, do you have a comment on this topic

Bryan: the question about URI resolvability and how to access stuff behind firewalls
... I don't think can be answered by the P+C or WARP spec
... the protocols of resource access should not be blocked by what we specified
... need to be very clear with wildcards, etc.
... but don't' think we need logical operators like "not"

MH: SteveJ's use case re UPnP and DLNA
... there is no way today to express those by the WARP syntax
... I think there is a need for a more flexible syntax
... we should include this UC in v1's model
... If we do what Steve proposes, we probably do not need the subdomains attribute

AB: we still have some issues to work thru before LC; please continue to discuss this on the mail list

VM-MF spec

AB: the FPWD of the VM-MF spec was published on Oct 6 ( http://dev.w3.org/2006/waf/widgets-vmmf/ ). Marcin already indicated some issues ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0047.html ). I think this spec needs a lot of work, especially regarding definitions (e.g. what does "application-like" mean), what is actually implemented versus what is "hints" to a UA etc.
... send comments to the list
... is there any particular group we should contact for review besides CSS WG

MH: just CSS

Updates spec

AB: the Charter of the Widget Updates PAG ( http://www.w3.org/2009/03/widgets-pag-charter#schedule ) expired 30 September. Presumably that means the PAG will soon complete its work with one of the so-called "PAG Conclusions" per the W3C Patent Policy ( http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-PAG-conclude ).
... this PAG operates on a Member-confidential mail list so we need to be careful not to disclose any Member-confidential information. That said, what can we tell the Public about our plans for this spec ( http://dev.w3.org/2006/waf/widgets-updates/ )?

MC: after the PAG's report is published, we can communicate what, if anything, will be changed
... I don't think we need to add any new features

AB: I think we have higher priorities ATM than this spec

MC: after the PAG publishes the report, the WG will need to review the recommendations and agree on what to do

URI spec: who do we ask to review the 8-Oct-2009 LCWD?

AB: the LCWD of the URI spec should be published today ( http://dev.w3.org/cvsweb/2006/waf/widgets-uri/Overview-LC.html ). Other than the TAG, who do we want to review that spec?

SP: could ask the HCG

AB: good point; I'll do that

MH: how about the people working on the IRI spec

AB: is that an IETF WG?

MH: yes plus others

AB: I'll pursue with the Team how to get review from IETF

<scribe> ACTION: barstow ask Team about how to get IETF review of the Widgets URI spec [recorded in http://www.w3.org/2009/10/08-wam-minutes.html#action04]

<trackbot> Created ACTION-415 - Ask Team about how to get IETF review of the Widgets URI spec [on Arthur Barstow - due 2009-10-15].

Requirements doc

AB: we haven't published the requirements doc in about a half-year ( http://dev.w3.org/2006/waf/widgets-reqs/ ). What's the pub plan for that Marcos?

MC: some reqs from WARP and URI spec need to be removed to the Reqs doc
... let's aim to get it published after the TPAC
... but get it ready to review during our Nov 2-3 f2f meeting

AOB

AB: any other topics for today?

FH: I updated Widgets DigSig example
... is there anything else that needs to be done?

MC: it puts conformance criteria on docs and UAs
... could create a TSE of that doc
... to change the conformance criteria
... to statements of facts
... then create test cases based on that
... will need to republish that doc after we've made the TSE changes

FH: not sure need a test for every MUST
... two categories of tests

MC: agree; we need to differentiate the two

FH: what's the prio of these tests?

MC: Kai is working on it now
... I am not personally involved with it
... but expect to get involved after the P+C is done
... it would be good if you FH could help
... e.g. to make sure we aren't creating tests that XML Sig tests

AB: anything else for today?

<fhirsch> Properties will need testing as well as widget specific processing.

<Steven> Regrets from me for the next two weeks

Benoit: who is attending TPAC?

AB: http://www.w3.org/2002/09/wbs/35125/TPAC09/registrants#apis
... Meeting Adjourned; next meeting same time on Oct 15

<Steven> Regrets from me for the next two weeks

<Marcos> ArtB: would this be sufficient?

<Marcos> Authoring Guidelines:Authors need to be aware that all elements, apart from the widget element, and related attributes are optional.

<Marcos> The following example shows the smallest possible configuration document that a widget user agent will be able to process.

- DRAFT -

Widgets Voice Conf

08 Oct 2009

Attendees

Contents