- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Thu, 18 Feb 2010 13:13:20 -0500
- To: public-webapps <public-webapps@w3.org>
The draft minutes from the February 18 Widgets voice conference are
available at the following and copied below:
http://www.w3.org/2010/02/18-wam-minutes.html
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
Approved.
-Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Widgets Voice Conference
18 Feb 2010
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0656.html
See also: [3]IRC log
[3] http://www.w3.org/2010/02/18-wam-irc
Attendees
Present
Art, Arve, Cyril, Marcos, Robin, Bryan, StevenP, Josh
Regrets
Frederick, Marcin, DavidR
Chair
Art
Scribe
Art
Contents
* [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 (
[12]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/06
56.html ). Are there any change requests?
[12] http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0656.html
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)" (
[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
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
[14]http://www.openmobilealliance.org/Technical/release_program/rme_
v1_0.aspx
[14] 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 (
[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
[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
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
"[19]http://www.w3.org/2005/11/its"; its|span::before { content:
"\202E"; } its|span::after { content: "\202C"; } actually *works* in
Firefox
[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