See also: IRC log
<artb> Date: 17 April 2007
<artb> Scribe: Cam
<artb> ScribeNick: heycam
RESOLUTION: f2f minutes will be public
AB outlines schedule
AB: widget requirements, we
should respond to bert bos' comments
... we'll get in to what's in scope of a widget platform
... anybody have any new inputs?
... guido has a widget signing input he wants to show
... i'd like to go through the red blocks in the spec, try to address the issue / assign an action
... we have quite a few of them
... with xbl2, i know jonas has submitted some comments and hixie hasn't responded yet
<Hixie> i'm not planning on answering xbl2 comments for some months, at least until we have more implementation feedback and enough changes to warrant going back to last call and sitting through another insane meeting with w3c management
AB: testing/interoperability, we should go through some ideas for testing models
AB: like to get a better sense of implementation plans
MC: LH, AVK and I did some work
on the xbl2 primer
... jose responded to my mail
AB: read access control, i have a
few editorial comments on the draft
... wasn't clear if all of marc's comments were addressed
AVK: he hasn't responded yet
AB: some open actions to assign
... since BP is leaving, we should close the taskforce
... DFAUI we're no farther ahead than we were in january, which is a big issue
... we'll have those two guys on the call tomorrow
... i'd be interested to get feedback from you guys here in this meeting
... finally, miscellaneous stuff
... charter update, since we're working on some thing which aren't really in the charter
... future f2f meetings, telcon frequency and time
... i'll be making a WAF presentation at WWW2007
... any other items to go through this week?
AB: we can go through bert's comments one by one
marcos's response to bert will serve as the record of the discussion for this part
AB: let's go through all of the
TODOs in the document and see if we can work on them
... has this version we're looking at been checked in?
MC: v1.21 should be up there
<artb> ACTION: Marcos Respond to Bert Bos with the agreements from the April 17 discussion. [recorded in http://www.w3.org/2007/04/17-waf-minutes.html#action01]
<trackbot> Created ACTION-78 - Respond to Bert Bos with the agreements from the April 17 discussion. [on Marcos Caceres - due 2007-04-24].
AB: any blocking things?
MC: mostly cosmetic at the
moment, it's starting to get stable
... now we need a lot of work on the spec
... we should keep updating the reqs document, based on what happens to the spec
... we should drop some reqs, based on them being out of scope, e.g. R26 ("accessing services")
AB: you could address it this way: most widget engines provide APIs to platform services, however such APIs are not within the scope of this work
MC: it's not worth dropping, since it's important, ...
AB: did we want to limit this
document to only the things we will address in Widgets
... i think it's good to be broader, but clear on which things are in/out of scope
... it's beyond the scope of the Widget packaging format specification
... some other TODOs in the appendices, i think
MC: this stuff i need to
... i may chuck this out
AB: are you concerend about keeping it up to date?
... there are sections that are going to take a long time to work out, such as the security model
AB: i'm not sure we could say a lot more from the reqs document about security
MC: microsoft/yahoo lets you do whatever you want, dunno about apple, opera is limited
AB: i'd be ok with leaving the three TODO blocks in the appendices for the next publication
MC: and if i can add more text from my other thing, i will as well
AB: that's pretty much it for the requirements
MC: looking at the first red
... we need to define classes of products
AVK: user agents, conformance
checkers, authoring tools
... i want to know how we'll progress on this spec
... i don't think we can have complete backwards compatibility with existing impls
... we should look at the widget updating, and if it's too hard, drop it for now
... mobile vs desktop widgets
... we should clearly look at what problems we are trying to solve with widgets
... the basic idea of updating widgets is clear, so i don't think we need to discuss that much
... the moment you get in to signing, updating, states, mobile vs desktop, it becomes more difficult
AB: wrt signing, we have a decent proposal that it would make sense to go through
AVK: there's also the microsoft thing, where they want the packaging as a means for distributing browser plugins
GG: what do we address first?
AVK: we can have a look at your stuff
GG: i think it would be useful if people would read it
AVK: read it tonight, do it tomorrow?
AB: do you want to do a quick intro?
GG: it suggests to use xml signatures and a specific variant of that, where the sig is stored outside the package that is signed
AVK: so that does interact with the updating
GG: it can still be inside the
package, but outside of the part that is signed
... i think all the rest is just the details about how xml signatures work
... the normative text is pretty short, at the bottom of the document
AB: should we at a minimum, add another red block in the spec?
AVK: i think updating has a red
... for downloading a widget, what's the easiest way for authors to do that?
... say you want to provide a separate version as a mobile widget
... do you have some sort of file that indicates use this one?
... or distribute it all in one?
AB: you think the spec should state that?
MC: might be part of the request header
AVK: the accept header is
... for simple widgets you would want just the one version
... a stock ticker would be easily cross platform
... the aquarium one though, that's quite a big widget
... on mobiles you might want to provide a different version
MC: i don't know if we need to deal with that level of complexity at this point
AVK: might have a startup file chosen based on media query
AB: sounds more like a best practice
AVK: you'd have to define the process of picking one
GG: you're proposing media query syntax in the config file?
... it doesn't address download size though
... the other similar issue is localised versions of widgets
GG: how would the syntax look like? like the yellow example on the screen? [examples from css3-mediaqueries]
... it'd default back to index.html (index.something), but if those elements are present, it'd pick one based on the media queries, in some defined order
... so authors can provide specific versions for mobile, if they really want
GG: an alternative way to do that would be to have the index.html that redirects based on the query
AVK: in theory you could do it
... probably doesn't make sense for language
GG: if you have the same simple
language, you might not want to duplicate the markup ten
... you're proposing at install time
... i'm proposing a decision the moment you fire up
AVK: well not install time, also run time
GG: then this config file queries are evaluated when the widget starts
AVK: no, you're right, it would
be stored after the initial time you run the widget
... so it is like "install" time
GG: there are some tricky cases, with device rotation changing screen size e.g.
MC: this'd be useful, but might be overkill for version 1
AVK: how do you want to address the mobile versions?
MC: maybe just make two versions of the widget
AVK: authors are giving feedback that they don't want to do that
GG: if you used the discovery
mechanism that you use further down, pointing to one package
all the time
... unless i have some crappy server side content switching, i always get the same package
MC: the option's always there to make a mobile specific version
GG: yeah, you can still do it in a different package
MC: i only looked at the MQ stuff briefly
GG: it has a very basic set of
device properties you can query for
... the dimension ones are the most useful
... there were a couple of other things, i was a member of the DI WG for a while, and they have zillions of properties that they think you should be able to query for
... not just the width of the viewport
LH: opera's got most of css3-mq implemented
GG: this is a css parser thing
MC: even if this was proposed for yahoo as well, they're starting to implement css
AB: back to how we advance the
... it's not going to advance without input for the red blocks
... helpful to have people commit to giving some input for a block
... or if people think a block should be deleted
... "what does it mean to conform to level 2.0 zip"
MC: there was a problem with
deflate64, i think
... i asked some opera engineers, and they didn't tell me why they fear the deflate64
... the other thing is to check this in the mobile space
AB: sounds like an action for me
AVK: is deflate64 patented?
MC: find out what capabilities to decompress zip files in the mobile space
<art> ACTION: barstow What are the ZIP capabilities for Symbian / S60? [recorded in http://www.w3.org/2007/04/17-waf-minutes.html#action02]
<trackbot> Created ACTION-79 - What are the ZIP capabilities for Symbian / S60? [on Arthur Barstow - due 2007-04-24].
AVK: we shouldn't create problems if we're not sure they exist
AB: We support zip.
... you can delete the issue, if that was all that was keeping it there
... when need a separate section about signing
AVK: i think we need an authoring
section that says how to construct a widget, and another
section, that says how to read the zip, parse the file,
... the processing model
MC: from request all the way to
... that's a structure problem, we can get back to later
... next box, folder structure
... that can also be done later
... content type?
AVK: once you have the processing model, you have the mime type
LH: should we define what happens if it's sent with the wrong mime type?
AVK: probably served as
... i'm fine with doing things easy for authors
... i dunno how people will react if we define sniffing for widget zip files though
... i'm not sure what the current processing model is. there are lots of ones on opera that have x-opera-widget
LH: that works if you have a central repo
AVK; we also have an offline loading processing model, which is different from the http one
AVK: can drag a config file onto
... it recognises it from the directory structure and name
LH: if it ends in .widget, see if it is an actual widget
next is whether a namespace is needed
AB: can we answer this question?
LH: why would it be useful to have one?
AVK: the answer [to whether we need one] is not clear
LH: only useful in multi-ns documents
AVK: for extensions e.g.
LH: not going to happen in a config file
AB: why don't we try to keep it simple for v1.0?
AVK: i suspect people will object to this
GG: any single widget implementation that uses namespaces?
MC: yes, yahoo, well they have a doctype i think
AB: without a compelling use case...
MC: except extensibility
GG: the only thing for extensibility is to skip over unknown elements
MC: we say this is an xml document, but we're going to say to do error handling, in as far as if you put in elements that are not recognised
GG: there's no schema though
MC: it's part of the processing model
GG: it's not unconforming, that
there's an unknown element
... every single widget runtime will have proprietary extensions
AB: hard to imagine that this is a complete set of elements.
AVK: they could propose new elements to the WG
AB: can't get consensus, just leave it as is
GG: i'm talking about schema syntax errors as opposed to xml syntax errors
MC: we need to address that as well, if we put proprietary elements, ...
GG: i want other engines to ignore the unknown elements
AVK: we could look at use cases
GG: like apple, they have a couple of elements related to security, and if we can't agree on that part, ...
AVK: the best thing is default to
no security, then have a webkit-security element, e.g.
... vendor prefixes instead of namespaces
... it should be part of the processing model
... if the xml fails to parse, then what should happen
... in opera, if the xml is not wellformed, it doesn't show the widget
AB: wrt licensing and copyright, i thought we talked about an element at one point. it never got added?
AVK: not clear how it should work
MC: just text
AB: what's existing practice?
AVK: if others do it, be
interesting to see what they do with it
... processed? or for other authors to look at?
LH: like rel=license?
AB: an optional element that might have something in there
AVK: best thing might be to provide a hyperlink
MC: yahoo has a copyright element
AVK: some people had extreme use cases, copyright per file, overboard
AB: so just add a copyright element?
license vs copyright
LH: license would be a link to the actual license text
AVK reads from HTML5, license and copyright act the same
MC: should be license instead of copyright?
MC adds a 'license' element to the spec
AB: next issue in 3.4, the id
... we skipped the width/height
GG: what do these values mean
AVK: these are
... you can do window.resize
... if you do that, you can no longer do 100%
AB: why are these two elements MUST?
AVK: opera requires them
MC: if you took them away, what happened?
AVK: it took the size of the previously opened widget
GG: if this is something that is required to be encoded, i think the 100% would be cool
AVK: (actually the default is 200x200)
MC: what about speccing a default value?
AB: seems like it should be left
to the implementation
... what additional information do we need for this one?
MC: if the w/h aren't present, it should default to 300x150?
AVK: do we want authors to have different default rendering depending on the device?
MC: css pixels deals with this
AVK: it deals with dpi
... width/height of the screen
GG: i don't want to ship 5 versions of the widget because of different screen sizes
AVK: device specific initial
... seems over engineered
... maybe simplest is to have width/height only apply to desktop browsers
... and mobiles default to fullscreen, unless in tiny mode
GG: devices without windowing systems can ignore the dimensions?
LH: if you use css, you could use media queries
AVK: the moment you create the
widget, you need to know the width/height
... it only seems to make sense on the desktop
... always display them at the given width/height, unless due to platform constraints you can't
AB: can we add that text?
AVK: might want percentages within width/height
CM asks about aspect ratio constrained widgets
MC writes some text in the spec to capture the width/height discussion
MC: we should consider the scenarios with mobile/desktop further
more discussion about width/height, where we decide they should be attributes instead of elements
AB: next, id element
AVK: until we make an update
mechanism, id is dropped
... if someone has a good solution, add it at that point
GG: dashboard have width/height as elements (in info.plist)
AVK: this is for updates, unique id for the widget
MC: yahoo has com.yahoo.widget.... just an identifier
AVK: if the processing model doesn't touch it, it's not useful
LH: how do you know if a widget
is a replacement for another?
... firefox extensions use UUIDs
AVK: what if you don't provide one?
GG: how do you update a widget?
AVL: you don't, you just install a new one and de-install the old one
LH: isn't that bad for usability?
AVK: the bad thing is that you
don't keep your data
... maybe the use case is that you have the identifier, and the UA makes it clear that this new widget will replace the old one
... replaces the widget files, but keeps the same data
GG: want a mechanism that's not just a download url
AVK: then you need another thing
to indicate the version
... something like atom, but that's probably too complex
... maybe just a floating point number?
... or 1.3.20 type of versioning (major/minor/...)
GG: dashboard has that x.y.z notation
LH: maybe id should be an attribute of the widget element
<anne> <widget version="1.1.1" id="http://www.w3.org/1999/#widget" width="200" height="400">
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/spec/requirements/ Succeeded: s/you address/you could address/ Succeeded: s/yeha/yeah/ Succeeded: s/request headers are/the accept header is/ Succeeded: s/versio n1/version 1/ Succeeded: s/namespace/namespaces/ Succeeded: s/AVL/AVK/ Succeeded: s/id attribute/id element/ Found Scribe: Cam Found ScribeNick: heycam Present: Art Cam Lachlan Marcos Anne Guido Agenda: http://lists.w3.org/Archives/Member/member-accesscontrol-tf/2007Apr/0000.html Found Date: 17 Apr 2007 Guessing minutes URL: http://www.w3.org/2007/04/17-waf-minutes.html People with action items: barstow marcos respond WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]