See also: IRC log
<trackbot> Date: 14 August 2008
<scribe> Meeting: Widgets Voice Conference
Date: 14 August 2008
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
AB: any change requests?
[None]
AB: we need to get clarity on the
contributors for OMTP's inputs before we can act on them
... any questions or concerns?
Nick: by contributors do you mean companies?
AB: yes I mean companies
AB: posted an update of the Turin
f2f agenda
... http://www.w3.org/2006/appformats/group/TurinF2F
... any comments?
[None]
AB: comments
http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/att-0298/MWBP_comments_to_Widget_Requirements_Last_Call_WD.htm
... 5 new reqs proposed
... and changes for R16 and R36
... unfortunately Bryan isn't here
... there are three thread now Marcos?
MC: yes
MC: we've talked about the
ontologies before in the context of device capabilities
... our general consensus in the past is this type of tech is
too complicated and not baked enough for v1.0
Arve: yes I agree with Marcos
AB: Mike and Nick?
Mike: I would like to hear from Nick about use cases and market realities
Nick: we do have device cap type
stuff in progress in BONDI
... it is an important topic
<marcos> +q
<Zakim> MikeSmith, you wanted to saymight be good to hear Nick's opinion on this
Nick: we are split on DCCI and simpler API based solutions
AB: I agree with Marcos' statements
Arve: device capability is too
complicated for v1.0; also think this issue will be less
important as platforms more powerful
... Widgets are NOT just for mobile
... For example, we ship Widgets for the desktop
... Thus I don't think DCCI, MWBP, etc. are relevant for a Core
Widgets spec
... If any mobile specific work needs to be done, it should be
in a separate spec
... or as extensions
<marcos> MC: I agree with Arve
AB: I agree with Arve's comments, pretty much 100%
AB: what are your thoughts on this Marcos?
MC: I don't think they understand
what the req says
... We don't expect "straight up" pixels
AB: the comments suggest two refs from the MWBP WG should be added
MC: I added the references in the Informative Ref section
AB: OK to me
... any other comments?
[None]
MC: I submitted some comments
http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0340.html
... I would reject this requirement
Arve: I pretty much agree with
Marcos
... in that it is not possible to know if a widget will be a
good or bad match for things like CPU or memory
<marcos> MC: the widget engine might not be good... but the widget might be ok
Arve: for example can't say
apriori anything about battery life
... This requirement could be satisified via a security
model
AB: has Bryan responded to your feedback Marcos?
MC: not yet and it's been almost one week
<scribe> ACTION: Barstow make sure all newbies in the WG understand our working mode regarding comments and responses [recorded in http://www.w3.org/2008/08/14-wam-minutes.html#action01]
<trackbot> Created ACTION-23 - Make sure all newbies in the WG understand our working mode regarding comments and responses [on Arthur Barstow - due 2008-08-21].
Mike: when responding formally to a comment it is always a good idea to include a deadline for responses
AB: that's an excellent point!
Mike: regarding the timeline, a
week is typically the best; 2 weeks if really needed
... want to eliminate chasing-up commentors if possible
... this will save time for everyone
AB: so in the abscence of pushback from Bryan and/or BP WG, that proposed Resource Declaration req will not be added
MC: I proposed some alternate text
AB: any feedback on Marcos'
proposed text?
... it's OK with me
... any other feedback?
[None]
MC: I'm OK with including this
AB: how would this req be manifested in a spec?
MC: good question; I think it
would just be a recommendation
... that is a recommendation for the UA
Arve: setting this depends on the
request itself
... what about loading external resources
MC: what happens now or what is proposed in HTML5?
Arve: HTML5 may not say anything
about the UA header
... I also don't quite understand how this req would be
specified
Mike: seems like this falls into
recommendations for UA behavior
... not sure we want to set a precedence for this
... it's a slippery slope for other UA behavior
... may want to say we don't want to define UA behavior at
all
AB: I agree with Mike
concerns
... OTOH, I think that type of doc is useful
... Is this something that would be more appropriate for the
MWBP's Web Apps recommendation?
<Zakim> MikeSmith, you wanted to say that including spec language to address this type of UA behavior might be a slippery slope
MC: I read the Web Apps doc from the MWBP WG and it is for developers not implemtors
AB: I don't see a match between
these 3 reqs and the set of specs we are working on
... I'm not opposed to adding these to an informative set of
recommendations
... for UA implementors
Arve: I'd like to see some Use Cases for these headers
MC: to me setting the UA header is typically self-evident
Arve: the problem with the UA
header is that it isn't authoritative
... in that anyone can set it to anything thus I question its
usefulneess
MC: so is it in or out
AB: I think it is more in scope
for a WG focusing on mobile specific requirements
... Nick, Mike?
<Zakim> MikeSmith, you wanted to say the MBWG is not chartered to produce specs that give normative conformance criteria for UAs
Nick: no input now
Mike: I think we're better off
not including it
... the MWBP is not chartered for creating Normative specs for
UAs
... Perhaps it could be a recommendation in BP v2.0 or
something like that
... Agree it shouldn't be addressed in the Widgets spec
AB: Propose we not add a
requirement for User-Agent header
... any objections?
Arve: no
Marcos: no
Mike: no
Nick: no
RESOLUTION: User Agent header will not be added to the Requirements document
AB: where is this header specified, Normatively?
MC: the CC/PP spec
<marcos> http://www.w3.org/TR/NOTE-CCPPexchange
AB: the NOTE reference is
Informative
... The W3C has produced a Recommendation for CC/PP and if we
use anything, we should use it
<arve> http://www.w3.org/TR/NOTE-CCPP/
<arve> http://www.w3.org/TR/2007/WD-CCPP-struct-vocab2-20070430/
<marcos> http://www.w3.org/TR/CCPP-struct-vocab/
AB: yes, that's it Marcos
... does this S&V spec define this header?
Arve: no, I don't think so
... My main concern is that it adds bloat for each request
without providing much value
... I don't think this is in widespread use
<MikeSmith> amen to what arve just said
MC: I agree
Arve: some of the properties simply are not useful
AB: Mike, Nick, any comments on this?
Mike: I agree with Arve
Nick: nothing to add
AB: I tend to agree with Arve as
wll
... Propose we do not add the U-A-Profile header to the
Requirements document
... any objections?
Marcos: no
Arve: no
Mike: no
Nick: no
RESOLUTION: We will not add the User-Agent-Profile header requirement
MC: when a UA makes a request, it
should use the Accept header
... Again, I think it should be a recommendation (like the UA
header)
Arve: UAs already do this
... Every widget engine will build on a browser engine and
support for this header will just be done
... Don't think we need to explicitly add it
AB: what would we add to our specs to satisfy this req?
Marcos: we wouldn't do anything
Arve: agree
... leave this to HTML5 for example
AB: Mike, Nick, any comments?
Mike: I agree with Arve and
Marcos; this should be left to HTML5
... IF it needs to be addressed at all
Nick: agree with Mike
AB: propose we not add the Accept
header as an explicit requirement
... Any objections?
[None]
RESOLUTION: we will not add the Accept header as an explicit requirement
MC: we already have a proxy
support requirement
... Bryan read an older version that was updated based on
feedback from Josh
Arve: what is the impact on our specs?
Marcos: I think it could be
related to our security model but I'm not sure
... I did add the rationale
Arve: not sure where we actually address this requirement
AB: which requirement is related?
MC: #39 http://dev.w3.org/2006/waf/widgets-reqs/#r39.-
AB: Arve, do you have problems with #39 as currently specified in the LC doc?
<marcos> http://dev.w3.org/2006/waf/widgets-reqs/#r41.-
<marcos> sorry
Arve: in practice all
implementations must support this req
... Proxy support will be required
... But it's not going to affect interop
... It doesn't affect how the widget will be written
Marcos: I agree; this is an
implemenation detail
... would like to hear about the security aspects
Nick: I agree need to separate security concerns
Mike: I agree with Marcos re this is an implemenation detail that we don't need to specifiy
AB: propse we not add this
requirement
... Any objections?
[None]
RESOLUTION: the new requirement for proxies will not be added
AB: Meeting Ended
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/req is relate/requirement is related/ Found Scribe: Art Found ScribeNick: ArtB Default Present: +44.771.414.aaaa, arve, nallott, Art_Barstow, marcos, MikeSmith Present: Art Arve Marcos Mike Nick Regrets: Thomas Claudio Luca Benoit DavidR Mark Agenda: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0399.html Found Date: 14 Aug 2008 Guessing minutes URL: http://www.w3.org/2008/08/14-wam-minutes.html People with action items: barstow[End of scribe.perl diagnostic output]