14:00:05 RRSAgent has joined #wam 14:00:05 logging to http://www.w3.org/2010/02/18-wam-irc 14:00:06 Steven has joined #wam 14:00:22 ScribeNick: ArtB 14:00:23 Scribe: Art 14:00:25 Agenda: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0656.html 14:00:26 Chair: Art 14:00:28 Meeting: Widgets Voice Conference 14:00:29 Date: 18 February 2010 14:00:31 Regrets: Frederick, Marcin, DavidR 14:01:00 zakim, aaaa is Cyril 14:01:00 +Cyril; got it 14:01:01 arve has joined #wam 14:01:09 +arve/marcos 14:01:44 +[IPcaller] 14:02:03 +Bryan_Sullivan 14:02:17 Present: Art, Arve, Cyril, Marcos, Robin, Bryan 14:02:46 right, even on IRC I don't even remember all the commands :( 14:03:25 Topic: Review and tweak agenda 14:03:32 AB: the agenda was posted yesterday ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0656.html ). Are there any change requests? 14:03:49 MC: I would like to talk about ITS 14:03:58 AB: we can add that to the P&C agenda topic 14:04:10 AB: any other requests? 14:04:12 [ No ] 14:04:19 Topic: Announcements 14:04:25 AB: does anyone have any short announcements? 14:04:30 zakim, dial steven-work 14:04:30 ok, Steven; the call is being made 14:04:31 +Steven 14:04:40 Present+ StevenP 14:04:48 Topic: ISO MPEG-U and Widgets 14:04:49 viper23 has joined #wam 14:05:03 AB: we have invited Cyril Concolato to join us today to discuss ISO's "Study text of ISO/IEC FCD 23007-1 (MPEG-U)" ( http://mpeg.chiariglione.org/working_documents/mpeg-u/pt1.zip ). Thanks for joining us today Cyril! 14:05:40 AB: Cyril, perhaps you could first give us a short overview of the group working on widget-related specs 14:06:09 CC: I am not talking on behalf of MPEG 14:06:19 ... I am only giving my personal point of view 14:06:34 AB: OK; thanks for that clarification 14:06:48 CC: MPEG-U is an ISO standard 14:07:03 ... it has multiple parts and only Part #1 deals with widgets 14:07:07 ... started Oct 2008 14:07:26 ... want solutions for widgets using MPEG technology 14:07:35 ... e.g. streaming widgets over MPEG-2 14:07:44 ... started with a reqs and context setting 14:07:53 ... both of those docs are publicly available 14:08:07 ... based on those reqs, MPEG made a RfP 14:08:18 ... we got some answers to that RfP and started a spec 14:08:33 ... we refer to WebApps' P&C spec and to what is nka TWI spec 14:08:45 ... We started a liaison at the end of 2009 14:09:04 ... it bounced around a bit (got lost) 14:09:12 ... so we sent a new liaision 14:09:55 ... we have people working on different MPEG specs e.g. audio, video, 3d, formats, scene description, LaSER, etc. 14:10:22 ... besides us, Telecom Italia, ETRI, Samsung, Intel (at one point in time) 14:11:09 ... we do ref P&C spec 14:11:29 ... expect an MPEG UA should be a P&C UA but also will include some extensions 14:12:02 ... We understand WebApps is starting charter discussions 14:12:08 ... want to collaborate on new work 14:12:27 ... there were two points, one technical 14:12:42 ... MPEG should split spec to confine some resualbe functions 14:12:48 ... the 2nd issue is IPR 14:13:00 ... MPEG does not work with Royalty Free by default 14:13:17 ... IPR policy allows for RF but that is not the default 14:13:30 +Josh_Soref 14:13:31 ... But MPEG is willing to change its widget spec so that is is RF 14:14:25 CC: need to clarify something in the minutes 14:15:35 CC: MPEG is requesting its members to send patent and licensing declaration forms 14:16:17 CC: this form allows MPEG members to declare that they are willing to provide the technology with RF terms 14:16:28 AB: thanks for those clarifications 14:16:43 AB: any comments about what CC has said so far? 14:16:54 Scribe+ Josh 14:17:02 ScribeNick: timeless_mbp 14:17:40 AB: I propose we go section by section, starting with section 1 ... 14:17:50 RB: I have 14:17:51 JS: I haven't had time to read the document 14:18:06 MC: I haven't reviewed it yet 14:18:13 AB: I have only glanced at it 14:18:51 AB: Robin, any comments on section 1? 14:19:02 CC: Section 1 is the scope, organization 14:19:12 RB: I have questions... 14:19:24 ... that would give people a better idea as they review it 14:19:37 ... first question: in your overview, it says that this new (?) 14:19:46 ... is meant to make it more compatible with existing ... 14:19:48 Present+ Josh 14:19:59 ... to help with widgets 14:20:07 ... to make it more compatible with e.g. flash 14:20:11 CC: ok... 14:20:20 ... when we had these requirements, we had several cases in mind 14:20:25 ... e.g. streaming 14:20:35 ... we wanted a configuration file to be able to point to a stream 14:20:50 ... we had a requirement that a widget using mpeg technologies should not require the use of scripting languages 14:20:59 ... i think that was the main two 14:21:08 ... it shouldn't say packaging format and configuration documents 14:21:13 "to ensure that the widget packaging format and configuration documents are compatible with the MPEG media types which can be used to describe widgets" 14:21:18 ... it should say general requirements 14:21:49 CC: the idea is. we wanted to investigate and standardize the additional things required to cope with mpeg media types 14:21:59 RB: the packaging and configuration shouldn't need to be changed 14:22:04 ... scripting is not required at all by P&C 14:22:15 ... pointing to a stream could be done with a URI 14:22:29 RB: another thing is "MPEGU would make it possible to 14:22:58 CC: the document is somehow related to the web, and you require/assume an http connection? 14:23:04 RB: no, no. not at all 14:23:18 CC: we're contemplating home devices without any internet connection 14:23:34 AB: this has been a concept from day one. e.g. exchanging widgets by bluetooth 14:24:43 s/MPEGU would make it possible to/MPEG-U intends to "ensure that it is targeted for additional domains than Web connected devices, e.g. broadcast, mobile or home networking domains."/ 14:24:52 bryan: as i review this spec, it seems to be coming from Interactive, multimedia application based 14:25:06 ... more similar to OMA (?) 14:25:10 ... scene management 14:25:27 ... incorporating discrete content and 14:26:00 ... cyril: is the goal here to make a profile more intended for incorporating streaming media into widget types of experiences? 14:26:23 CC: yes, I wouldn't say primarily, but one of the goals is to facilitate the use of widgets in streaming environments 14:26:33 bryan: what you're talking about here is a packaging format for those types of applications 14:26:38 CC: there are two aspects 14:26:41 ... one is widget communications 14:26:46 ... the other is widget packaging 14:27:00 CC: packaging covers streaming or packaging multimedia files in a container 14:27:12 bsulliva has joined #wam 14:27:14 CC: the other which covers communication is quite different 14:27:19 s/bryan/BS/g 14:28:01 RB: a few quick points... 14:28:07 ... in terms of intrawidget communication 14:28:18 ... i think it might be worth it to look at post methods (?) and web sockets 14:28:28 ... i understand those may not fit the exact use cases 14:28:39 +1 on reuse as much of Web Sockets and Post Message as possible 14:28:40 ... but they do have the value of being implemented in existing implementations 14:28:49 s/post methods/Post Message/ 14:28:58 .... and they have security analysis and acceptance 14:29:10 RB: the other thing that might be worth looking into is Mozilla Weave 14:29:20 ... which I've been asking mozilla to push towards standards 14:29:26 ... it's certainly something to look at 14:29:36 RB: that's all i had for section one 14:29:39 AB: anyone else? 14:29:46 OMA RME specs I mentioned are at http://www.openmobilealliance.org/Technical/release_program/rme_v1_0.aspx 14:29:48 JS: My word processor doesn't like me 14:30:03 AB: comments on references, definitions, abbreviations, or conventions? 14:30:09 RB: references point to an editors draft? 14:30:14 AB: they're definitely out of date 14:30:17 CC: they need to be updated 14:30:42 AB: the more interesting parts of the document starts in chapter 7 14:30:48 ... a composition section, lifecycle 14:30:53 ... perhaps some overlap with our update spec 14:31:03 AB: robin, do you want to comment? 14:31:13 RB: a brief comment on lifecycle, table 1 14:31:18 ... widget events (?) 14:31:26 ... it seems that some of that may overlap with ViewModes 14:31:35 ... for instance there's a HideShow (?) event, that's when the widget is hidden 14:31:41 ... it might be good to reuse the same stuff 14:31:49 ... i know that view modes isn't completely specified at this point 14:32:01 ... and it wouldn't cover the entire set of events, because we don't have a life cycle at this point 14:32:06 CC: that's a good comment 14:32:13 ... i think there is some overlap with View Modes 14:32:19 MikeSmith has joined #wam 14:32:36 ... one of the use cases we want to address 14:32:53 ... is how do you cope with a widget which has two live representations? 14:32:59 ... is this something you cover in view modes? 14:33:01 RB: I don't think so 14:33:20 MC: to clarify something with view modes 14:33:35 ... i don't see the relevance of separate instantiations 14:33:45 ... it's not about synchronizations of views 14:33:57 RB: that's why i said there was some overlap, but not complete overlap 14:34:03 ... something with shown or not 14:34:12 ... but there's also stuff which is completely separate 14:34:24 s/MC:/ABe:/ 14:34:50 RB: some people have said they'd like a life cycle specification 14:34:56 ... but they haven't put the work into it 14:35:00 ... i'm not sure it's needed 14:35:09 AB: i agree with RB 14:35:12 MikeSmith has left #wam 14:35:23 ... i think it would be interesting to look at if someone were to contribute it 14:35:44 ABe: i don't see it as a viable working item 14:35:57 AB: if no one puts forward a proposal, that would be the default 14:36:05 AB: did you guys, CC work on the update problem? 14:36:41 q+ 14:36:42 CC: no. we referenced your update spec, and when you moved it away 14:36:52 ... we didn't really have a way to handle it 14:36:59 ... we moved it to the references section 14:37:02 ... we didn't know what to do 14:37:11 AB: you didn't do extensions there? 14:37:26 AB: I think for some elements you made extensions, but not update? 14:37:33 CC: yes, none for update 14:37:40 BS: about the lifecycle... 14:37:57 ... it has more to do with the activation of a scene 14:38:04 ... and the synchronization 14:38:06 CC: yes 14:38:25 BS: i think that's more in line with what i talked about earlier .. rich media environment OMA 14:38:30 ... and i dropped a link earlier 14:38:41 BS: I think that's been outside the scope of what widgets have focussed on 14:39:03 ... i don't think there's anything in widgets that deals with scene at all 14:39:08 ... and therefore lifecycle is not relevant 14:39:46 BS: our view modes deal with window state 14:40:02 ... not really the same as multiple synchronized representations 14:40:06 AB: ok, continuing... 14:40:08 ... section 7 14:40:22 AB: comments on ? 14:40:27 CC: one comment on Communication 14:40:32 ... using postMessage and 14:40:45 q- 14:40:46 CC: we had a strong requirement that communication should be possible without scripting 14:40:55 ... the idea was to be able to implement it in very limited devices 14:41:00 ... e.g. UPnP light bulbs 14:41:13 ... should be able to communicate with MPEG widgets 14:41:17 ... without any scripting 14:41:24 ... that's what drove the design of this communication part 14:41:53 ABe: isn't that down to protocols 14:41:57 ... outside the scope of a widget 14:42:05 +1 to Arve 14:42:05 ... it's a general web problem 14:42:15 ... what you're looking for is a general protocol problem 14:42:23 CC: i think it's related to the previous problem 14:42:34 ... what the w3 group describes in terms of widgets 14:42:40 ... is not related to scene layers 14:42:56 ... and that's what the bits we've described is for 14:43:02 ABe: don't misunderstand me 14:43:08 ... things like this do fit into the problem of the web 14:43:10 q+ 14:43:21 ... but i believe that problem should be looked at in a different context than widgets 14:43:38 ... if you're looking at the UPnP problem of wanting to turn down lights while watching a movie 14:43:44 ... it's a protocol for interacting with limited devices 14:43:51 ... i'm a bit unsure if this is in the device api land 14:43:57 ... or if it's in the scope of the widget wg 14:44:04 ... or if it belongs somewhere else 14:44:10 AB: i briefly looked at 7.3 14:44:24 ... and it looks like you could replace widget implementation with web browser 14:44:39 BS: i think this is talking about concepts again which are well beyond the current functions of a web browser 14:44:51 ... i think this is along the lines of service discovery 14:44:56 ... services, i give them URNs 14:45:08 ... i run in an environment which discovers services 14:45:16 ... peer to peer, media servers, .... 14:45:26 BS: i think this is more, not a web concept, a UPnP concept 14:45:35 ... this is far beyond the concept of a web browser 14:45:53 AB: the point of agreement here is that the type of functionality described in 7.3 is out of scope for web apps 14:46:03 ... we should move on 14:46:09 ... section 7.4. comments? 14:46:36 q- 14:46:50 AB: i need to look at it in detail 14:47:02 CC: the general idea is that we serialize preferences that the widgets change / modified 14:47:08 ... and we exchange it 14:47:24 ... this serialized format is related... using the element from P&C 14:47:30 AB: other comments on section 7? 14:47:32 ... ok section 8 14:47:46 ... RB? 14:48:02 RB: can you clarify the difference between (un?)packaged and the web site? 14:48:17 CC: ok, we want to be able to deliver packages in an MPEG2 carousel 14:48:20 the difference is in the availability of a manifest - this does not occur for websites 14:48:31 ... the carousel has the ability to deliver updates to fragments 14:48:37 ... you deliver the carousel 14:48:48 ... and then later the broadcaster can deliver an update to one files 14:48:51 s/files/file/ 14:49:07 ... you might also want to be able to request for proper content from a web server 14:49:16 ... the config.xml might say that the start file is available in 3 formats 14:49:25 ... SVG, XML, HTML 14:49:37 ... and depending on the device, you might want to request only one format 14:49:52 this is actually one of the weaknesses of unpackaged widgets - you can't use the same code for the widget in both cases, or use the config.xml directives in the website 14:49:52 RB: i'm surprised that's not already supported by the spec 14:50:05 q+ 14:50:05 CC: there's no mime type for the config.xml file 14:50:12 RB: that's the next question 14:50:18 CC: if you dig up previous versions of this spec 14:50:27 ... we asked if the w3c should standard the mime type of the file 14:50:42 ... i asked on the list, and the response was that someone didn't think it was a good idea 14:50:55 ... we decided to standardize it, but only when it deals with mpeg extensions 14:51:10 RB: it's generally not a great idea to register a media type for a file format 14:51:14 ... that someone else is handling 14:51:17 CC: i agree, but... 14:51:32 RB: what's wrong with using application/xml ? 14:51:40 ABe: i think application/xml is the right thing to use here 14:51:52 ... serving config.xml over the network has never come up as a use case 14:52:02 ... if you're serving single files over the web 14:52:09 ... why not call them web applications 14:52:10 q? 14:52:13 ... and serve them directly 14:52:21 ... if you're trying to use the web directly 14:52:31 ... you're going against the reason widgets were created in the first place 14:52:40 CC: we have use cases where files are not delivered in a zip 14:52:48 ... they're delivered in something equivalent to a zip 14:52:58 ... in the MP4 file format 14:53:05 ... it's similar for the MP2 carousel 14:53:08 ... but we need a mime type 14:53:32 ... and we need to indicate that the config.xml is not a generic xml file 14:53:36 ... but has specific meaning 14:53:45 CC: i'm open to suggestions 14:53:49 AB: i seem BS is on the queue 14:54:00 BS: I put a couple of points in the chat 14:54:06 ... first, we have a solution for this 14:54:11 ... the browser downloads the widget 14:54:20 ... and plays the files from the package 14:54:31 ... i agree that there's no way to characterize the manifest of a web site 14:54:46 ... i agree that there should be no difference between the package you can create using a packaged or unpackaged format 14:54:51 ... i think that's a weakness 14:55:06 ... maybe you can solve that by downloading and using directly in the browser a widget package 14:55:13 q- 14:55:16 CC: but there are cases when you don't wan to get the whole package 14:55:20 ABe: which cases are that 14:55:24 s/that/that?/ 14:55:34 ... and how are they not solved in the web setup at large? 14:55:42 ... (by caching) 14:55:51 BS: if you're asking me, it's because caching is nondeterministic 14:56:00 ... caching is a problematic thing... best effort 14:56:08 ABe: i'm struggling to see this 14:56:17 ... how is this not solved by e.g. html5 offline applications 14:56:25 ... ? 14:56:40 ABe: if you want to do this.... 14:56:53 ... because you are trying to do something which is rather different than what widgets were supposed to be 14:56:59 ... the rational needs to be extremely clear 14:57:04 ... which use cases are you solving? 14:57:06 q+ 14:57:21 ... what are you getting by using widgets instead of other container formats? 14:57:25 ack bsulliva 14:57:35 BS: my use case is that i don't want to develop my web application twice 14:57:41 ... in terms of packaged/unpackaged use 14:57:53 ... I discover it on the web, and it's cached using html5 caching directives 14:58:07 ... i shouldn't have to develop my web application using two separate semantics 14:58:12 AB: time check 14:58:25 AB: i want to talk about p&c 14:58:44 AB: i'd like to stop talking about section 8, and encourage people to continue on the list 14:58:48 ... moving to section 9. RB? 14:58:58 q- 14:59:01 ScribeNick: ArtB 14:59:27 -Steven 14:59:49 RB: what formalism is used in Section 9? 14:59:54 ... not Web IDL 15:00:03 CC: you are correct; we can use Web IDL 15:00:23 RB: can you reuse of the existing stackes re messaging protocols? 15:00:46 s/reuse/reuse one/ 15:00:52 CC: for example? 15:01:00 RB: well, there is CORBA 15:01:13 ... and other stuff [missed it] 15:01:25 q+ 15:01:30 ... the spec doesn't cite other related work 15:01:54 CC: the API for comm is coupled with the XML format 15:02:05 ... can take a look at this to see if we can improve it 15:02:13 ... but we want it to work without scriptiong 15:02:47 JS: wondering about search ifc 15:02:53 ... but it isn't defined anywhere 15:03:03 CC: used in the example 15:03:25 s/search ifc/search ifce/ 15:03:49 AB: anything else on section 9? 15:04:05 ... let's move then to section 10 Manifest 15:04:29 > For elements defined in W3C WPC no prefix is used. 15:04:32 RB: small nit about some prefix usages 15:04:35 s/WPC no/WPC, no/ 15:04:56 ... can't really constrain this 15:05:09 CC: agree should be bound to the namespace defined 15:05:20 ... I'll fix it, just let me know 15:05:23 > ‘urn:mpeg:mpegu:schema:widgets:manifest:2010’. 15:05:37 RB: using URN for namespace prefix is considered bad practice 15:05:51 CC: if it is bad practice, we can change it 15:05:54 ... use URL? 15:05:56 RB: yes 15:06:03 CC: not sure if we can modify it 15:06:13 RB: helps with discoverability for humans and computers 15:06:36 RB: type attributes, you'd like to see them in the W3C spec? 15:06:39 CC: which element? 15:06:57 where is that good/bad namespace decl practice identified (URN vs URL)? in a W3C document? that would be useful to know. 15:07:20 AB: which section? 15:07:38 CC: 10.2, the first extension attribute 15:07:50 RB: I don't think we want to add it to P&C spec 15:07:57 ... should make it multi-value 15:08:15 RB: proc model for multiple instances is a bit fuzzy 15:08:23 ... needs to be clearer 15:08:26 CC: OK 15:08:43 RB: also naming and camel case needs some work 15:08:46 CC: ok 15:09:01 RB: not sure about the release date? 15:09:08 ... how does it work with updates? 15:09:15 CC: P&C has version attribute 15:09:20 > Optional. A boolean which indicates if multiple instances of this widget will present different results (multipleInstances==“true”) or not. If not specified, the default value is “false”. 15:09:23 q+ 15:09:31 ... requires number and name 15:09:35 ... we may just have date 15:09:38 q+ 15:09:44 RB: can have anything you want in version 15:09:53 ... can verify with MC 15:09:58 MC: it is just a string 15:10:21 AB: we probably tightened it in a later spec 15:10:39 JS: re multiple instances 15:10:53 ... think the wording is confusing 15:11:00 CC: yes, that's the same comment as RB 15:11:26 RB: author should be able to define if multiple instances are possible or not 15:11:35 CC: think this is for the UA not author 15:12:06 JS: think the UA should be able to implement it as it wants 15:12:16 CC: this attribute is a hint 15:12:24 RB: not sure the hint is needed 15:12:35 ... e.g. if no prefs 15:13:14 JS: don't like the author to be able to overly constrain the UA 15:13:28 q- 15:13:46 BS: a key extension is on the element and their new attrs 15:14:05 ... think we need to get feedback on multiple content elements 15:14:06 [can mw:discardable be ignored by the UA at user option? it's not something that should be enforced] 15:14:15 CC: we will drop width and height 15:14:15 darobin: +1 15:14:18 [how is mw:uuid different from @id] 15:14:26 q- 15:14:27 ... but want multiple content in the config file 15:14:32 ... and want W3C to define it 15:15:02 covers 'types' with locales 15:15:03 AB: where do we submit comments? 15:15:13 i don't think that types and locales are compatible typically 15:15:18 CC: use public-webapps 15:15:54