[widgets] Draft minutes from 18 February 2010 voice conf

The draft minutes from the February 18 Widgets voice conference are  
available at the following and copied below:


WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before February 25 (the next  
Widgets voice conference); otherwise these minutes will be considered  

-Art Barstow


       [1] http://www.w3.org/

                                - DRAFT -

                        Widgets Voice Conference

18 Feb 2010


       [2] http://lists.w3.org/Archives/Public/public-webapps/ 

    See also: [3]IRC log

       [3] http://www.w3.org/2010/02/18-wam-irc


           Art, Arve, Cyril, Marcos, Robin, Bryan, StevenP, Josh

           Frederick, Marcin, DavidR




      * [4]Topics
          1. [5]Review and tweak agenda
          2. [6]Announcements
          3. [7]ISO MPEG-U and Widgets
          4. [8]P&C spec: proposal to publish PR
          5. [9]Status
          6. [10]AOB
      * [11]Summary of Action Items

    <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 (
    56.html ). Are there any change requests?

      [12] http://lists.w3.org/Archives/Public/public-webapps/ 

    MC: I would like to talk about ITS

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

    [ No ]


    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)" (
    [13]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

      [13] http://mpeg.chiariglione.org/working_documents/mpeg-u/pt1.zip

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

    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
    ... 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
    ... i understand those may not fit the exact use cases

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

    RB: but they do have the value of being implemented in existing
    ... and they have security analysis and acceptance
    ... the other thing that might be worth looking into is Mozilla
    ... 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

      [14] http://www.openmobilealliance.org/Technical/ 

    JS: My word processor doesn't like me

    AB: comments on references, definitions, abbreviations, or

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

    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
    ... SVG, XML, HTML
    ... and depending on the device, you might want to request only one

    <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

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

    BS: my use case is that i don't want to develop my web application
    ... in terms of packaged/unpackaged use
    ... I discover it on the web, and it's cached using html5 caching
    ... 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

    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

    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

    <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

    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 (
    [15]http://www.w3.org/2005/10/Process-20051014/tr.html#cfr ). The
    P&C CR's status section defines exit criteria (
    [16]http://www.w3.org/TR/2009/CR-widgets-20091201/#sotd ). I think
    we have met both criteria.
    ... what is the ITS test suite status?

      [15] http://www.w3.org/2005/10/Process-20051014/tr.html#cfr
      [16] http://www.w3.org/TR/2009/CR-widgets-20091201/#sotd

    MC: I created ITS tests

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

      [17] 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> \

      [18] http://dev.w3.org/2006/waf/widgets-bidi/Overview.src.html

    MC: my proposal is a new spec that defines what the bidi element
    ... 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

    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


    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


    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
    "[19]http://www.w3.org/2005/11/its"; its|span::before { content:
    "\202E"; } its|span::after { content: "\202C"; } actually *works* in

      [19] http://www.w3.org/2005/11/its

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

    <Marcos> right

Summary of Action Items

    [End of minutes]

Received on Thursday, 18 February 2010 18:14:22 UTC