IRC log of wam on 2010-02-18

Timestamps are in UTC.

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