Widgets Voice Conference -- 18 Feb 2010

<ArtB> ScribeNick: ArtB

<scribe> Scribe: Art

Date: 18 February 2010

<Cyril_Concolato> right, even on IRC I don't even remember all the commands :(

Review and tweak agenda

AB: the agenda was posted yesterday ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0656.html ). Are there any change requests?

MC: I would like to talk about ITS

AB: we can add that to the P&C agenda topic
... any other requests?

[ No ]

Announcements

AB: does anyone have any short announcements?

ISO MPEG-U and Widgets

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!
... Cyril, perhaps you could first give us a short overview of the group working on widget-related specs

CC: I am not talking on behalf of MPEG
... I am only giving my personal point of view

AB: OK; thanks for that clarification

CC: MPEG-U is an ISO standard
... it has multiple parts and only Part #1 deals with widgets
... started Oct 2008
... want solutions for widgets using MPEG technology
... e.g. streaming widgets over MPEG-2
... started with a reqs and context setting
... both of those docs are publicly available
... based on those reqs, MPEG made a RfP
... we got some answers to that RfP and started a spec
... we refer to WebApps' P&C spec and to what is nka TWI spec
... We started a liaison at the end of 2009
... it bounced around a bit (got lost)
... so we sent a new liaision
... we have people working on different MPEG specs e.g. audio, video, 3d, formats, scene description, LaSER, etc.
... besides us, Telecom Italia, ETRI, Samsung, Intel (at one point in time)
... we do ref P&C spec
... expect an MPEG UA should be a P&C UA but also will include some extensions
... We understand WebApps is starting charter discussions
... want to collaborate on new work
... there were two points, one technical
... MPEG should split spec to confine some resualbe functions
... the 2nd issue is IPR
... MPEG does not work with Royalty Free by default
... IPR policy allows for RF but that is not the default
... But MPEG is willing to change its widget spec so that is is RF
... need to clarify something in the minutes

<Cyril_Concolato> CC: MPEG is requesting its members to send patent and licensing declaration forms

<Cyril_Concolato> CC: this form allows MPEG members to declare that they are willing to provide the technology with RF terms

AB: thanks for those clarifications
... any comments about what CC has said so far?

Scribe+ Josh

<scribe> ScribeNick: timeless_mbp

AB: I propose we go section by section, starting with section 1 ...

<darobin> RB: I have

JS: I haven't had time to read the document

MC: I haven't reviewed it yet

AB: I have only glanced at it
... Robin, any comments on section 1?

CC: Section 1 is the scope, organization

RB: I have questions...
... that would give people a better idea as they review it
... first question: in your overview, it says that this new (?)
... is meant to make it more compatible with existing ...
... to help with widgets
... to make it more compatible with e.g. flash

CC: ok...
... when we had these requirements, we had several cases in mind
... e.g. streaming
... we wanted a configuration file to be able to point to a stream
... we had a requirement that a widget using mpeg technologies should not require the use of scripting languages
... i think that was the main two
... it shouldn't say packaging format and configuration documents

<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"

CC: it should say general requirements
... the idea is. we wanted to investigate and standardize the additional things required to cope with mpeg media types

RB: the packaging and configuration shouldn't need to be changed
... scripting is not required at all by P&C
... pointing to a stream could be done with a URI
... another thing is "MPEG-U intends to "ensure that it is targeted for additional domains than Web connected devices, e.g. broadcast, mobile or home networking domains."

CC: the document is somehow related to the web, and you require/assume an http connection?

RB: no, no. not at all

CC: we're contemplating home devices without any internet connection

AB: this has been a concept from day one. e.g. exchanging widgets by bluetooth

BS: as i review this spec, it seems to be coming from Interactive, multimedia application based
... more similar to OMA (?)
... scene management
... incorporating discrete content and
... cyril: is the goal here to make a profile more intended for incorporating streaming media into widget types of experiences?

CC: yes, I wouldn't say primarily, but one of the goals is to facilitate the use of widgets in streaming environments

BS: what you're talking about here is a packaging format for those types of applications

CC: there are two aspects
... one is widget communications
... the other is widget packaging
... packaging covers streaming or packaging multimedia files in a container
... the other which covers communication is quite different

RB: a few quick points...
... in terms of intrawidget communication
... i think it might be worth it to look at Post Message (?) and web sockets
... i understand those may not fit the exact use cases

<ArtB> +1 on reuse as much of Web Sockets and Post Message as possible

RB: but they do have the value of being implemented in existing implementations
... and they have security analysis and acceptance
... the other thing that might be worth looking into is Mozilla Weave
... which I've been asking mozilla to push towards standards
... it's certainly something to look at
... that's all i had for section one

AB: anyone else?

<bsulliva> OMA RME specs I mentioned are at http://www.openmobilealliance.org/Technical/release_program/rme_v1_0.aspx

JS: My word processor doesn't like me

AB: comments on references, definitions, abbreviations, or conventions?

RB: references point to an editors draft?

AB: they're definitely out of date

CC: they need to be updated

AB: the more interesting parts of the document starts in chapter 7
... a composition section, lifecycle
... perhaps some overlap with our update spec
... robin, do you want to comment?

RB: a brief comment on lifecycle, table 1
... widget events (?)
... it seems that some of that may overlap with ViewModes
... for instance there's a HideShow (?) event, that's when the widget is hidden
... it might be good to reuse the same stuff
... i know that view modes isn't completely specified at this point
... and it wouldn't cover the entire set of events, because we don't have a life cycle at this point

CC: that's a good comment
... i think there is some overlap with View Modes
... one of the use cases we want to address
... is how do you cope with a widget which has two live representations?
... is this something you cover in view modes?

RB: I don't think so

ABe: to clarify something with view modes
... i don't see the relevance of separate instantiations
... it's not about synchronizations of views

RB: that's why i said there was some overlap, but not complete overlap
... something with shown or not
... but there's also stuff which is completely separate
... some people have said they'd like a life cycle specification
... but they haven't put the work into it
... i'm not sure it's needed

AB: i agree with RB
... i think it would be interesting to look at if someone were to contribute it

ABe: i don't see it as a viable working item

AB: if no one puts forward a proposal, that would be the default
... did you guys, CC work on the update problem?

CC: no. we referenced your update spec, and when you moved it away
... we didn't really have a way to handle it
... we moved it to the references section
... we didn't know what to do

AB: you didn't do extensions there?
... I think for some elements you made extensions, but not update?

CC: yes, none for update

BS: about the lifecycle...
... it has more to do with the activation of a scene
... and the synchronization

CC: yes

BS: i think that's more in line with what i talked about earlier .. rich media environment OMA
... and i dropped a link earlier
... I think that's been outside the scope of what widgets have focussed on
... i don't think there's anything in widgets that deals with scene at all
... and therefore lifecycle is not relevant
... our view modes deal with window state
... not really the same as multiple synchronized representations

AB: ok, continuing...
... section 7
... comments on ?

CC: one comment on Communication
... using postMessage and
... we had a strong requirement that communication should be possible without scripting
... the idea was to be able to implement it in very limited devices
... e.g. UPnP light bulbs
... should be able to communicate with MPEG widgets
... without any scripting
... that's what drove the design of this communication part

ABe: isn't that down to protocols
... outside the scope of a widget

<darobin> +1 to Arve

ABe: it's a general web problem
... what you're looking for is a general protocol problem

CC: i think it's related to the previous problem
... what the w3 group describes in terms of widgets
... is not related to scene layers
... and that's what the bits we've described is for

ABe: don't misunderstand me
... things like this do fit into the problem of the web
... but i believe that problem should be looked at in a different context than widgets
... if you're looking at the UPnP problem of wanting to turn down lights while watching a movie
... it's a protocol for interacting with limited devices
... i'm a bit unsure if this is in the device api land
... or if it's in the scope of the widget wg
... or if it belongs somewhere else

AB: i briefly looked at 7.3
... and it looks like you could replace widget implementation with web browser

BS: i think this is talking about concepts again which are well beyond the current functions of a web browser
... i think this is along the lines of service discovery
... services, i give them URNs
... i run in an environment which discovers services
... peer to peer, media servers, ....
... i think this is more, not a web concept, a UPnP concept
... this is far beyond the concept of a web browser

AB: the point of agreement here is that the type of functionality described in 7.3 is out of scope for web apps
... we should move on
... section 7.4. comments?
... i need to look at it in detail

CC: the general idea is that we serialize preferences that the widgets change / modified
... and we exchange it
... this serialized format is related... using the <preferences> element from P&C

AB: other comments on section 7?
... ok section 8
... RB?

RB: can you clarify the difference between (un?)packaged and the web site?

CC: ok, we want to be able to deliver packages in an MPEG2 carousel

<bsulliva> the difference is in the availability of a manifest - this does not occur for websites

CC: the carousel has the ability to deliver updates to fragments
... you deliver the carousel
... and then later the broadcaster can deliver an update to one file
... you might also want to be able to request for proper content from a web server
... the config.xml might say that the start file is available in 3 formats
... SVG, XML, HTML
... and depending on the device, you might want to request only one format

<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

RB: i'm surprised that's not already supported by the spec

CC: there's no mime type for the config.xml file

RB: that's the next question

CC: if you dig up previous versions of this spec
... we asked if the w3c should standard the mime type of the file
... i asked on the list, and the response was that someone didn't think it was a good idea
... we decided to standardize it, but only when it deals with mpeg extensions

RB: it's generally not a great idea to register a media type for a file format
... that someone else is handling

CC: i agree, but...

RB: what's wrong with using application/xml ?

ABe: i think application/xml is the right thing to use here
... serving config.xml over the network has never come up as a use case
... if you're serving single files over the web
... why not call them web applications
... and serve them directly
... if you're trying to use the web directly
... you're going against the reason widgets were created in the first place

CC: we have use cases where files are not delivered in a zip
... they're delivered in something equivalent to a zip
... in the MP4 file format
... it's similar for the MP2 carousel
... but we need a mime type
... and we need to indicate that the config.xml is not a generic xml file
... but has specific meaning
... i'm open to suggestions

AB: i seem BS is on the queue

BS: I put a couple of points in the chat
... first, we have a solution for this
... the browser downloads the widget
... and plays the files from the package
... i agree that there's no way to characterize the manifest of a web site
... i agree that there should be no difference between the package you can create using a packaged or unpackaged format
... i think that's a weakness
... maybe you can solve that by downloading and using directly in the browser a widget package

CC: but there are cases when you don't wan to get the whole package

ABe: which cases are that?
... and how are they not solved in the web setup at large?
... (by caching)

BS: if you're asking me, it's because caching is nondeterministic
... caching is a problematic thing... best effort

ABe: i'm struggling to see this
... how is this not solved by e.g. html5 offline applications
... ?
... if you want to do this....
... because you are trying to do something which is rather different than what widgets were supposed to be
... the rational needs to be extremely clear
... which use cases are you solving?
... what are you getting by using widgets instead of other container formats?

BS: my use case is that i don't want to develop my web application twice
... in terms of packaged/unpackaged use
... I discover it on the web, and it's cached using html5 caching directives
... i shouldn't have to develop my web application using two separate semantics

AB: time check
... i want to talk about p&c
... i'd like to stop talking about section 8, and encourage people to continue on the list
... moving to section 9. RB?

<scribe> ScribeNick: ArtB

RB: what formalism is used in Section 9?
... not Web IDL

CC: you are correct; we can use Web IDL

RB: can you reuse one of the existing stackes re messaging protocols?

CC: for example?

RB: well, there is CORBA
... and other stuff [missed it]
... the spec doesn't cite other related work

CC: the API for comm is coupled with the XML format
... can take a look at this to see if we can improve it
... but we want it to work without scriptiong

JS: wondering about search ifce
... but it isn't defined anywhere

CC: used in the example

AB: anything else on section 9?
... let's move then to section 10 Manifest

<timeless_mbp> > For elements defined in W3C WPC, no prefix is used.

RB: small nit about some prefix usages
... can't really constrain this

CC: agree should be bound to the namespace defined
... I'll fix it, just let me know

<timeless_mbp> > ‘urn:mpeg:mpegu:schema:widgets:manifest:2010’.

RB: using URN for namespace prefix is considered bad practice

CC: if it is bad practice, we can change it
... use URL?

RB: yes

CC: not sure if we can modify it

RB: helps with discoverability for humans and computers
... type attributes, you'd like to see them in the W3C spec?

CC: which element?

<bsulliva> where is that good/bad namespace decl practice identified (URN vs URL)? in a W3C document? that would be useful to know.

AB: which section?

CC: 10.2, the first extension attribute

RB: I don't think we want to add it to P&C spec
... should make it multi-value
... proc model for multiple instances is a bit fuzzy
... needs to be clearer

CC: OK

RB: also naming and camel case needs some work

CC: ok

RB: not sure about the release date?
... how does it work with updates?

CC: P&C has version attribute

<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”.

CC: requires number and name
... we may just have date

RB: can have anything you want in version
... can verify with MC

MC: it is just a string

AB: we probably tightened it in a later spec

JS: re multiple instances
... think the wording is confusing

CC: yes, that's the same comment as RB

RB: author should be able to define if multiple instances are possible or not

CC: think this is for the UA not author

JS: think the UA should be able to implement it as it wants

CC: this attribute is a hint

RB: not sure the hint is needed
... e.g. if no prefs

JS: don't like the author to be able to overly constrain the UA

BS: a key extension is on the <content> element and their new attrs
... think we need to get feedback on multiple content elements

<darobin> [can mw:discardable be ignored by the UA at user option? it's not something that should be enforced]

CC: we will drop width and height

<timeless_mbp> darobin: +1

<darobin> [how is mw:uuid different from @id]

CC: but want multiple content in the config file
... and want W3C to define it

<timeless_mbp> <content> covers 'types' with locales

AB: where do we submit comments?

<timeless_mbp> i don't think that types and locales are compatible typically

CC: use public-webapps
... if we have any liaison to go back, making it Public is OK

<timeless_mbp> ABe: +1 :)

Arve: what is the IPR status?
... we need to be careful here

CC: per ISO rules, MPEG has asked its members to make RF declarations for its widget spec
... we will send more information to WebApps when we have it

Arve: think we should stop discussions until the declarations are made

<timeless_mbp> +1

<timeless_mbp> of note, we required the previous group that joined to play by the same game

CC: I'm not sure when we'll have all of the declaration forms

Arve: I don't think we should continue until we have such delcarations

RB: we can send feedback
... but we cannot use their input without RF declarations

AB: agree with that

<timeless_mbp> the previous group was OMTP

AB: thank Cyril
... if you have comments send them to public-webapps

CC: I can put some demo videos on our web site

P&C spec: proposal to publish PR

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.
... what is the ITS test suite status?

MC: I created ITS tests

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

AB: will the impl report separate Mandatory versus Optional tests?

MC: not yet, but it will
... will try to finish that today

AB: when you are done with those edits, will it show 3 impls pass 100% of the Mandatory tests?

MC: yes, that is correct
... we also have the http tests
... no commitments yet to implement ITS
... I created 15 ITS test cases

<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).

MC: I can't find any place in the ITS spec anywhere that indicates the above text
... it is underspecified re how we want to use it
... If no one is implementing ITS, perhaps we should drop it

AB: the flip side is that since it is optional

<Marcos> \ http://dev.w3.org/2006/waf/widgets-bidi/Overview.src.html

MC: my proposal is a new spec that defines what the bidi element does
... and define a span element in the widget namespace

AB: what are other's thoughts here?

RB: I'm OK with dropping it if we don't have to go back to LC
... but I could live with going back to CR
... would like to drop it and go to PR

MC: agree with RB
... it was earlier at risk

AB: we can continue to discuss this with the team to determine with a way forward
... we can drop it then a 2nd decision is if we ever want to specifiy something

MC: without some spec prevents stuff like intermixed Hebrew with other langs
... we will need this at some point

JS: there must be a way to do this with just unicode markers
... think we're trying to solve a prob that is already solved with unicode

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

Status

AB: postpone Dig Sig until next week as well as View Modes

RB: I have some changes to make for URI scheme spec and then need to start correspondence with IETF

MC: no activity on update spec

AOB

AB: any short topics?

MC: hope to get an update of Update spec out next week

AB: next call is February 25; meeting adjourned

<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

<darobin> if I were an evil guy I could support this natively in Widgeon

<darobin> muahaha, it works in Opera too! (cc Marcos)

<timeless_mbp> heh

<darobin> and in Chrome/Safari

<darobin> well, if anything I believe that this shows that ITS is actually not really needed, *[dir=ltr] ought to be sufficient

<Marcos> right

- DRAFT -

Widgets Voice Conference

18 Feb 2010

Attendees

Contents

Review and tweak agenda

Announcements

ISO MPEG-U and Widgets

P&C spec: proposal to publish PR

Status

AOB

Summary of Action Items

Scribe.perl diagnostic output