2-3 Semptember 2010
Hosted by W3C/Keio, Tokyo, Japan
The Ministry of Internal Affairs and Communications, Japan, supports this workshop.
<kaz> (nothing to record)
jan: question about IP connection
yosuke: 20% of TVs in Japan are IP reachable
... Web apps, e.g., twitter, are available on TV
... on the other hand TVs don't necessarily need IP connection
since they can use broadcasting radio wave
ph: how popular is interactive TVs in Japan?
... do you think it's successful?
yosuke: interactive TV service is
available without IP connection (but only using radio wave
connection), so not completely sure about the actual ratio...
... however, I can say during an interactive part of a TV program
with a 40-50 parcent audience rating could include 300,000
accesses from the audience within two minutes.
... note that in Japan all the TV system will change to digital in July 2011
... currently the rate of digital service deployment is 80%
... but the information on that kind of interactive TV service is
not well appealed to the audience
Jun Murai: the default configuration
of interactive data connection is "on" in digital broadcasting
... however, most people ara not aware and it's difficult to get
precise statistics
Yasuko Tsuda: question about contents check of Web applications for TV programs, e.g., twitter
Mari Shimizu: two of our employees checked abuses, slanders, etc. based on the broadcasting codes before we put twitter contents on a TV program
... but actually there were not so many problems
Takashi Matsuzawa: one of the questions about IP TV service is data traffic, isn't it?
yosuke: actually, even application distribution is possible using radio wave
... so we should be able to make the traffic reasonably low and use limited bandwidth effectively
leonard: how can users input data, e.g., for chat application? using usual remote controller for TV?
Nippon TV: software keyboad is available now
... and actual USB keyboards should be also available in the future
leonard: how broad is the bandwidth for TV programs?
yosuke: digital terrestrial television uses 1-2Mbps
... so the bandwidth is rather narrow, and we need to use data compression for image and audio
daniel: what kind of new requirements??
yosuke: many requirements for business-based services
... how to update existing mechanism, etc.
<homata> Is CE "Consumer Electronics"?
<jinhong> yes. I mean low performance devices
<homata> I see, Thanks
<jinhong> The TV and STB has low performance than PC
<iga> 50 000 000 househouds in Japan. Viewsers for the program was etimated as 40% of households . 300 000 pepole who voted via Internet is 1.5% of viewsers.
→ 5-min presentation x 6 (=30mins)
→ 60-min panel discussion including brief summarization of topics discussed during the session
<MikeSmith> first up is Habu-san from ARC
Habu: we will use
BML as an example, look at the TV from a platform
perspective
... there are so many different additional apps required by the market
... which lead us to some high-level requirements
<MikeSmith> [see slide with requirements]
Habu: BML was developed by the Japanese org ARIB
... it shares some characteristics with [the HTML+CSS+JS, etc., standard Web platform]
-> http://www.w3.org/2010/09/web-on-tv/papers/ARC.pdf Habu-san's paper
Habu: there are a variety of APIs
in BML, including an API for caption control
... final note: We need to look into potential privacy issues
in much more detail
next up is Yamada-san from IPTV Forum
-> http://www.w3.org/2010/09/web-on-tv/papers/StatementsOfInteret_IPTV_Forum_Japan_.pdf Yamada-san paper
=> http://www.w3.org/2010/09/web-on-tv/slides/20100902IPTVFJ_WebOnTVWorkshop.pdf Yamada-san slides
Yamada: [gives background on the Japan IPTV Forum]
... among other things, we do publish technical specs
... major operators and device makers are involved in this forum
... Jun Murai (Keio University WIDE project, etc.) is an advisor
Yamada: we are trying to produce standards for implementations
... in cooperation with broadcasters also
... we will be producing [have already produced] a report, and it will be available in English too
Yamada: we have submitted some
specs to the ITU, and they will be published by ITU
... our standards are implemented in VOD (Video on Demand)
players
[Yamada-san gives demo of a particular VOD service currently deployed in Japan]
next up is Yu-san of DragonTec
-> http://www.w3.org/2010/09/web-on-tv/papers/AplyforW3CWorkShop.pdf Yu-san slides
Yu: we provide some BML products
next up is Imai-san from Cisco
Imai: network infrastructure is going to need to change to support TV
-> http://www.w3.org/2010/09/web-on-tv/papers/Cisco.html Yu-san's paper
next up is Jan Lindquist of Ericsson
Jan: I'm here to give an intro about the Open IPTV Forum
... we have more than 60 members
... our representation is quite broad
[Jan gives details about some features provided on Open IPTV-enabled devices]
next up is Kawamori-san
Kawamori: I'm here to talk about ITU-T
... we are a unit within the United Nations
... and we are working on TV standards
... we meet every two or three months
... we are working on interoperability
-> http://www.w3.org/2010/09/web-on-tv/papers/ITU-T.html Kawamori-san's paper
Kawamori: we are working with other SDOs
... including W3C
... we have been working on interactive frameworks
... with HTML, CSS, SVG
... reflected in the H.762 ITU standard
... which is an international standard for IPTV
... this part is a browser-based solution, including the technologies I mentioned above, and Javascript
... it also uses the Lua programming language
... and SMIL
<kaz> W3C Liaison list
Kawamori: the H.762 standard has some similarities to BML
-> http://www.itu.int/md/T09-SG16-091026-TD-PLEN-0172/en Draft new ITU-T Recommendation H.762 (ex H.IPTV-MAFR.2) "Lightweight interactive multimedia framework for IPTV services (LIME)"
kaz gives a high-level summary of the session
<chaals> [Multiple approaches: evolve BML, OIPF, ITU-T, ...]
Habu: we can think of the Web a being a new feature that's being added to TVs
Yamada: so yeah, this is about adding additional features to TVs
Yu: it's also about the fact that users can use a single device, a single terminal, to access a wider variety of services [including the Web]
Imai: Web-on-TV and TV-on-the-Web are closely related
Jan: it's about integrating the TV visuals with the browser capabilities, with Web technologies
Kawamori: a question is, do we want everything on the Web to be available on TVs?
... do you want viruses on your TV?
... do you want your TV to go blank for a month?
... or do we need some kind of management of the Web?
... multimedia hinders search, hinders Web competence [sic]
Kawamori: we have to think about the management issue
<chaals> [I disagree. Web is significantly based on applications now - and multimedia is more and more feasible to automatically interpret/manipulate/etc (SVG is an example of making the technology support that, auto-captioning via speech reco is an example of getting better at doing it]
... broadcasters don't want their content to be accessible from browsers
<chaals> [management of content is indeed an important issue, for TV, the Web and beyond]
Google announced that they are now indexing SVG content on the Web, and have added the capability to do searches for specific kinds of SVG content
<Daniel> comments to kawamori's opinion: we already have that event in W3C as Video on the Web 2008, and three working groups are now working, and going to the W3C recommendation. Web on TV should be different from multimedia/video oriented on the web.
<Daniel> wow, PC and TV is same platform ? I do not agree...
<chaals> [it has been possible to search SVG for a long time (there are many many search engines in the world, and a lot of important data isn't available to the general public anyway). Things like automated translation of automatically generated captions are still poor quality, but for the purpose of discovery they are pretty useful already]
<Daniel> if that happens, nobody can enjoy their life with TV anymore. TV is still lean-back device.
<chaals> Youtube/Hulu/Daliymotion/etc are part lean-back, but allowing lean-forward. Your football team on TV is pretty lean-forward, and people alreday use twitter/facebook/etc to make it so when their TV doesn't provide that.
<Daniel> please buy more TV for family personalization...just joking.
<jinhong> I think, TV remains lean-back device, but web services on TV appear lean-forward style.
<chaals> [part of the value to broadcasters is to create stickiness by offering the lean-forward interactions that users always got from the web, and that mobile providers have learned to offer as they shift from walled gardens to something like "managed" gardens]
<ddahl> although with web on TV maybe there's actually a process of going back and forth between lean forward and lean back at different times
<chaals> [Good point about the fact that many people can use a TV who aren't comfortable using web-enable devices. Looking at teletext usage in europe bears this out - many people can use interactive hypertext systems if they seem simple enough, even if they won't go near a computer or mobile phone]
<ddahl> sometimes you just want to lean back and be entertained
<Daniel> lean-forward and lean-back at different times. agreed, but to me web is rushing to make viewers lean-forward regardless of users intention.
<chaals> [definitely. Otherwise the video services on the Web wouldn't work]
<chaals> [I think a lot of web usage is lean-back. Lean-forward engages the user, so it's a device to increase user involvement (which is a good thing for marketing stuff to them).]
<jinhong> I agree with daniel, when I using web it make me lean-forward.
<chaals> [Kawamori-san - 'who owns the display' matters now. But I think 'who owns the remote' still matters when you are thinking about what users do with TV]
chaals: question: What's the value of making TV a "lean-forward" activity?
... which means, what's the value in making it something that users interact *more* actively than they do today
Habu: because users have already changed their style of watching TV
... now for some users, when they watch TV, they expect information about the current program and such to be immediately avaiable
<jinhong> right. They want to use web services at the same time
... that can be thought of a particular "style" of watching TV
... one of many possible such styles
... so we need to support a variety of styles of TV interaction
... [including both the "lean back" and "lean forward" style]
Jan: in, e.g., a game show, you want the interactivity
... but if you are watching a movie, you don't want that
... but that said, you may still want to pause it
... uses want the _liberty_ to personally control their viewing experience
<chaals> [Hmm. recording and watching, vs the experience of sharing a TV show or a football match in real time]
Kawamori: users "zap" through TV channels in a way that is similar to the way they search or browse the Web
Jan: I would like the panel to comment on the personalization aspect
<chaals> [I wonder how people useTV. In autralian homeland settlements, one TV is used more like a cinema, but in US houses it seems everyone has their own as well as the one in the living room]
<jinhong> In my case, I have two TVs on my house. ;-)
I would like to ask if anybody on the IRC channel knows about DVB-HTML and can comment on it here
<ddahl> we have 4 (we live in the US) as well as two TV tuners for other displays (PC and projector)
-> http://en.wikipedia.org/wiki/DVB-HTML DVB-HTML (Digital Video Broadcast HyperText Markup Language)
Kawamori: it should be noted that
BML is not a single language -- it is a set of
specifications
... LIME (H.762) borrows some APIs from BML, but that's it
<chaals> [LIME and BML are extended subsets of a collection of languages, which have chosen different subsets and added different extensions, as well as some extensions that are common to the two]
... otherwise, LIME is based more directly just on HTML, CSS, and other W3C technologies
Kawamori: we use a spec for a version of Javascript that is not completely conformant with the ECMAScript standard, so we can't call it ECMAScript
<inserted> http://-> www.itu.int/itu-t/recommendations/rec.aspx?id=10642 LIME specification
→ 5-min presentation x 7 (=35mins)
→ 65-min panel discussion including brief summarization of topics discussed during the session
<chaals> [INCITS has another remote UI approach, and I suspect there are more]
narm: compatibility with existing
technologies
... HTML5, JavaScript, CSS, Ajax, ...
... CE-HTML, Remote UI
... User interactivity standards
... e.g., touch I/F
<jinhong> dear ddahl, Is that deal with multitouch interface in W3C multimodal WG?
daniel: Internet@TV
... Widgets for TV
<plh> jinhong, no, it's an extension to dom level 3 event. it will be part of the touch interface working group
daniel: games, skype, etc.
<jinhong> okey. thanks.
daniel: what is expected from
W3C?
... smarter or cozy better on TV?
... HTML5 is really a killer app?
... "Web on TV" vs. IPTV
dongyoung: expanding Web
technology on TV
... mobile, home appliances, etc.
... convergence services
... richer user experience by Web technology like smart
phones
... cheaper development using standard technology
... different target? TV's target has been passive and relaxed
user experiences
... resource issue
... TVs are watched from a distance
... remote controllers
... What to do then???
... consolidate fragmented standards
<jinhong> Check the korean translation service. out of sound.
<hidetaka> available on ch. 1
<hidetaka> :(
<jinhong> now on ch. 3
<jinhong> ;-)
shinji: note define public
protocol between TV & other devices
... generalization of "Web on TV"
... 1. push mechanism (receiving data from outside)
... 2. get information from each TV device (personalization,
device capability)
... for new richer user experience
kotaro: what is most
impportant?
... e.g., remote controller!
... typically many independent controllers are required
... user him/her-self has to manage all the controllers
... small characters are difficult to see
... we should re-define what "remote controller" means
... all the information could be handled within a smarter
controller (e.g., iPho
ne)
scribe: merits for both users and service providers
aaron: several use cases
... @@@usecase1
... @@@usecase2
... usecase3: PC to TV recommendation
... several requirements:
... compatible experiences - unified UI to acess the contents
and services from different Web sites
... convergence
... possible architectures:
... managed architecture vs. unmaged one
... the difference is whether TV service provider is involved
or not
... concerns:
... usedr account etc.
... QoE
... UI for TV
tatsuo: existing IPTV
system
... multicast/unicas
... STB (set top box) features:
... - channel selection
... - EPG (electronic program guide) and ECG (electronic
content guide)
... - recording reservation
... use case1: channel selection
... use case2: EPG
... EPG rights to be discussed
... use case3: recording reservation (from outside of
home)
... using smartphone etc.
Florian Rivoal, Opera
scribe: BML for mobile devices??
tatsuo: using compact HTML
florian: controlled content vs. open one?
<chaals> s/... BML and for mobile devices/iMode and WML were based on walled gardens and we have seen the open web competing - what are the differences between the mobile market and the TV world/
tatsuo: we're not providing
actual content to mobile devices
... but probably need to consider contents right in the
future
jan: CE-HTML?
<jinhong> yes. CE
narm: HTML, JavaScript and CSS
are included in that
... in the future, CE 2014 might refer W3C's standards
daniel: if W3C want to cope with
CE devices, it would be great
... we have already DAP group within W3C
... don't have any specific opinion about that, though
<jinhong> now dongyoung before, danel
kotaro: myself didn't mean reuse
of CE-HTML
... but we should be able to consider use cases first
tatsuo: agree we should think about use cases first
mike: some comment on whether
CE-HTML etc. should be brought to W3C or not...
... we didn't coordinate before
<chaals> [+10 to Mike's comments]
mike: video scripting is now
available in HTML5
... we should think about problems and use cases
... before considering solutions
LG: question to Samsung
<chaals> Mike: Don't just bring a finished spec to W3C and expect it to be adopted, it doesn't work.
yosuke: question about remote
controller
... agree controller is important
... question to Access
... difference from mobile phone as controller
(i-Aprication)
... question to UIE
... what if IP connection is not available?
... any fallback plan?
shinji: making TCP/IP connection easy to people would be useful
kotaro: not as a substitute of IR-based controller but smarter I/F
daniel: question to
audience
... I was wondering about people's expectation
... which direction to go?
... personally think "smarter TV" would be useful than "more
convenient TV"
... what do you think?
jan: do you mean making TV something like PC?
daniel: you need more smarter
interaction, controller, etc.
... but is that "a smarter PC" or "a PC with a big
screen"?
... smart TV for living room (= more interactions)
... while "cozy" device means "just watch programs"
dongyoung: being "smart" vs. "cozy" is my question as well...
jan: iPhone is getting
interactive apps using the internet
... ifyou take mobile as an example, TV is perfect
... I prefer "cozy" :)
charles: different way of
thinking
... How much does industry want people to buy "smarter
TV"?
... different use cases
... people not comfortable with PCs, who now use teletext (like
very basic BML from 1980s), will be getting more
interactivity
... People who use smartphones and PCs already will move their
interaction to that device if TV isn't useful enough for doing
the things they want to do already
... when I watch football, I just watch football, but I send
messages to people who I think are watching too
... or do we want to watch on PC, where I can already send
messages to other people watching?
debbie: user experience of PC and use experience of TV seems quite different
leonard: activities users
need
... the advantage of TV makers is
... making device like TV capable
yosuke: from our viewpoint (who
is working with broadcasters very closely)
... broadcasters are expected to provide service like
water
... we need to consider which side of TV we're discussing
<inserted> Yosuke mentions TV as public service and TV device
→ 5-min presentaion x 3 (=15mins)
→ 65-min panel discussion including brief summarization of topics discussed during the session
yosuke will be moderating
kitamoto: what do you mean by TV? device or service provider, my preference is TV as a metaphor
,,,TV is very important in an emergency -- my
project is "Digital Typhoon", integration of many sources of
information
...http: //www.digital-typhoon.org
... includes satellite images of this morning
... when the typhoon is approaching, there is a lot of
information coming in.
... you might want something to be pushed.
<scribe> ...new program is more like Twitter
kim: from W3C Korea Office
... Nomadic TV among multi-domains
... focus on IPTV
... issues -- what is TV and what sort of standard is
required?
... what is TV?
... now we have various services, e.g. Google TV, various
standards like LIME, the challenges can be opportunities
... My use case is a service that was realized in the lab. the
user is watching TV, but then has to travel, and then he can
watch the same content on a mobile device.
<chaals> [hmm. Opera implements widgets on TV (currently moving from Opera widgets which were the initial basis of W3C widgets to the final W3C widgets standards)]
kim: issues- user interface,
presentation, etc, (many issues listed on slide)
... some issues are dealt with in W3C and some are not
maruyama: (from NTT Cyber
Solutions)
... use case Advanced IPTV Services
... background, current Japanese IPTV, based on standards
defined by IPTV Forum, Japan
... can use BML if you have a BML-enabled device
... BML and LIME, both are based on Web standards
... ITU-T Rec H.762, (LIME) is an international standard and
can handle many languages
... BML vs. HTML, comparison --navigation via remote vs. mouse
and keyboard
... layout is absolute in BML but browser-dependent in
HTML
... media type is selected in BML but many in HTML
... BML is used as the basis for the evolution of IPTV
<Florian> ["can handle many languages" refers to human languages, not mark up languages. This is in contrast with Japan only technologies.]
maruyama: combination of VOD,
Web, and broadcast
... three-screen linkage (DTV, PC, Mobile Device)
... our objective is enabling these services, but there are
concerns -- performance on resource-limited devices
... need to identify optimal profile, another concern is
security
yosuke: we have had three presentations, different perspectives from reseachers. questions?
jan: how is VOD supported (broadcast, IP)?
maruyama: guarantee of quality is
another issue, in IPTV Forum there is a specification for open
Internet and CDN
... when we handle other types of content in the future,
content delivery to end users need to have the quality of
content guaranteed.
... has to be made available in the network.
jan: has IPTV Forum addressed the
quality of service question?
... (QoS)
maruyama: we have the QoS assumption as a prerequisite
jan: is this a managed network?
yosuke: there are both open internet and managed available
matsuzawa: Is the assumption with
BML that it's user-independent, or can it be changed for
accessibility purposes? for example, font sizes
... if I have some preference in viewing something, how can
that be accommodated?
matsumura (NHK): in NHK, for visually disabled we accommodate presentation, sometimes it's impossible to change the font, we could use text-to-speech but it's difficult to tell where to start.
scribe: we don't have any viable
solutions yet
... this is not a new requirement, we want to maintain the
requirement and we want to have some type of accommodate
ashimura: in multimodal
interaction and voice interaction, we have some interest in
accessibility and would like to ask if people if this is
important
... we need to identify all the topics for future work
yosuke: will the three presenters talk about accessibility
kitamoto: users may be friendly with the web but having different ways to view is expected now
kim: the W3C in Korea we see some issues in accessibility because of regulation
maruyama: accessibility is taking
us toward a more convenient form of usage
... when you think of remote control management, you could put
something on a remote control device
yosuke: specific comments on accessibilty
taisuke: accessibility is much discussed in HTML5, so perhaps we can use it
yosuke: we are looking at BML and
LIME because the use cases apply to Web on TV
... we could just focus on HTML5 when we talk about
accessibility
maroka??: does Web on TV require accessibility or not? does user need "read aloud" functionality? if someone can't use hands, do we need to offer an easier to operate functionality.
scribe: if accessibilty is required can we use HTML5
chaals: (from Opera) works on
accessibility in HTML5. older users are people who use TV but
not computers, accessibility is important for them.
... we do need some, but how much do we need is an open
question
... HTML does include a lot of capability, but you don't get
everything by using HTML, you have to do this correctly and
browsers have to do what they need to do.
... we should mark it down as something we need. certainly
there are some things we need, like font size, not sure about
TTS, most blind users I know don't watch TV on television
... but watch on PC
... some requirements are obvious but some might be too
expensive and that market is lost. But it is important to note
that it isn't just one user, but their friends as well, because
people share situations - if you go to a bar and someone is in
a wheelchair everyone in the group will go to the bar that is
accessible, and the inaccessible bar loses the entire group
oura: (from Airframe) we need to
have accessibility, push information is hard to get for
visually disabled people
... disabled people now find it difficult to access
information
<chaals> [With audio description, captioning, there are still many possibilities on TV, and until recently every blind person I knew watched TV on TV. The question is whether we can build new technology well enough to keep it useful]
yosuke: summarize discussion --
the scope of accessiblity is to take care of disabled people,
also some people who need accessibilty aren't necessarily
disabled.
... accessibility helps people participate in social
life.
... any other comments?
<chaals> [We *can* make the technology accessible. We just need to make sure that we plan for it and implement it properly as we are developing technology. Often it is difficult to get it right afterwards.]
<chaals> [Hmm. Thinking about the first use case presented today by NHK, of providing important information such as natural disaster warnings, it is probably quite important to get it right...]
kim: for TV, the smart TV is for people in general, the situation might be more complex, the smart TV might make the situation more difficult.
yosuke: accessibility becomes more difficult as TV becomes smarter.
chaals: not necessarily, it's important to look at what solutions have been developed. not a complicated technical problem, if we set the requirements and look at what other people have done.
yosuke: I'd like to take as many questions as possible:
jan: a question about the
emergency situation. do you see the need to provide a real-time
push with video or audio in addition to the pictures?
... where do you get additional information?
... do you need additional information to present?
Kitamoto: the more information
the better, so there is no limitation about how much
information to present
... we can increase the information sources
ashimura: can include sensor
information as well, like rain gauge
... in the push model
funahashi: this ties into the datacast presentation from this morning
matsumura(NHK): emergency information is one of the major missions of broadcasters
scribe: datacast needs some kind of summarization so that it can be delivered in a push model
yamamoto: (from Technicolor)
about natural disaster information, suppose an emergency
happens where you live but you're not watching a
broadcast
... how can emergency information be conveyed to a viewer in
that case?
???: (from Dwango) when we talked about accessibility we talked about how far to offer support, I wonder what broadcasting people think is too expensive or too compllicated. is there a guideline of some sort?
chaals: in certain countries
there are legal requirements for things like captioning and
audio description
... there are strong requirements in the US and UK and they're
getting stronger over time
seki: about accessibility and
BML, this was a requirement from the beginning. we wanted to
make the load on the receiving device as light as possible
(1998).
... NHK does captioning almost 100%, commercial stations have
about 50%, now viewers' age is increasing, for example as
people become older it becomes more difficult to hear
things.
... captioning is provided even for commercials
<chaals> [/me notes that where content is generated from a script (e.g. commercials, drama) the data required is already available - the issue is just how you present it. In live-generated content it can be more difficult - but it is still pretty cheap compared to the cost of TV production) ]
???: there will be an event in Geneva in December on accessibilty of IPTV
ashimura: announcements. at 6:00 in lounge we will have a welcome dinner.
→ 5-min presentaion x 4 (=20mins)
→ 70-min panel discussion including brief summarization of topics discussed during the session
presenters are Charles McCathieNevile (Opera Software), Hiroshi Omata (Jig.jp), Kazunori Tanikawa (NEC), Masao Goho (Microsoft)
Charles: I'll talk about why I
think HTML5 is important in this context.
... people didn't want very careful thought out
technology
... and HTML5 is different from previous specs: HTML4, WML,
XHTML2
... HTML5 allows you to create applications
... the Web is applications
... new in HTML5 [...]. Not in HTML5: geolocation, transition,
webfonts, database storage, ...
... they are all part of the same technology platform
[demo]
Charles: vdeio requirements:
captioning, audio description, poster, etc. question is what's
the first priorities?
... device apis are also important
... JIL, BONDI -> WAC -> W3C
... SMS, contacts, camera
... the mobile world learned: you use HTML5
... offline apps
... widgets, appcache, storage apis, web storage, database
apis, etc.
... How W3C works?
... requirements, proposals
... working group charter
... drafts, wide review
... start talking to w3c when you think you understand your
requirements
... don't go to W3C with a finished specification and try to
get adopted. W3C will want to make sure if it fits the needs of
the rest of the world
[HTML5 video demo: http://craftymind.com/factory/html5video/CanvasVideo.html ]
Hiroshi: my company is developing
jigbrowser, a browser for mobile phone
... also doing jigmovie
... jig twi, a twitter client
... this application converges twitter with browser
... I'd like to focus my talk on application side
... there are 3 areas of interest to the market
... television control decide
... device api for television
... broadcasting
... so television control device
... rather than using the remote from the tv, you could use
other devices, such as a wii
... device api for television
... with them, we'll be able to do more, eg, using the browser
on the mobile, you can display a remote control for the
television
... web and broadcasting convergence
... eg
<chaals> [If you have device APIs, and a browser, you can use any HTML browser to control the TV with a webserver. The idea of Opera Unite is to make it easy to build systems like this for any pair of devices (Opera Unite is really just a webserver built into the browser)]
<video> <source src='tv:1ch'/> </>
Hiroshi: this will give us more
opportunities
... maybe in the future, we'll be able to see any web pages on
the television
<jinhong> Also using device APIs, I want to control TV tuner on my TV.
<chaals> [Web browsers on the TV that also give access to the open web have been around for years]
<jinhong> like channel control
Tanikawa: involved ITU-T
standardization
... regarding a11y: how can we provide communitcation tools for
people with disabilities
... W3C has already made great contributions to a11y
... such WACG 1.0, 2.0
... examples of improvements
... by using CSS, we could adapt the page for color visual
impairment individuals
... protanopic, deuteranopic, tritanopic
... other example is emergency alerts
... it's very important to have secure communication
tools
... with HTML5, how we present the information is
important
... Web sockets, web messaging can be candidate for
solutions
... we need to identify more specific solutions
... whether it's done at W3C or not, I don't know
... Emerging UI
... HTML5 offers a good opportunity to create new consumption
style on TV
<jinhong> Does a member of DAP participate in W3C on this workshop?
jinhong, I don't believe so, or maybe chaals is
<chaals> I am not a member of DAP, but Opera is involved there (and in WAC, which is working on things that need to be done in DAP)
Masao: the role of HTML5 in the Web on TV
<chaals> [No flash in my demos]
Masao: devices: we have different
devices as a platofrm
... and now the TV is supported
... HTML5, if we case use it as a common platform, we have to
think how it will be used
... Contents: existing BML (BML to HTML5?)...
... for instance, for touch interface, it depends on the
devices
... if you have touch screen functionalities, you want to sit
far away from the screen
... but you may have a device in front of you
... content: two ways communication. how active are the
users?
... if it's a must requirement, should it be done by the TV,
and how do we use it?
... let me talk about IE9
... trying to put together some platform
... we'll like to get your feedback
Debbie: I'll like to open the
discussion to the rest of the group
... any question for the speakers?
Daniel_Park: HTML5 seems to be
very nice from a Web prospective. PC is a good platform.
... all of HTML5 is not possible on other devices
... we need to prioritize the functionalities from TV
prospective
Charles: At Opera, we expect to
make HTML5 on all our supported devices. we run opera mini on
very basic telephone
... we haven't got a complete HTML5 implemetation because the
spec isn't finished yet
... in terms of prioritizing: the success of the iphone proves
that you don't need to meet carrier certifications
... but every carrier in the world wants to have it, because
it's an attractive platform
... the same applies to android
... dont' spend time thinking very detailed requirements and
priorities, spend that time developing a platform that
works
... we're in the business of providing services
... HTML5 is designed so it can be ran on all devices
... we produced opera on all kind of devices
... trying to prioritize isn't worth of time
... we'll spend millions of dollars being irrelevant to the
market
Hiroshi: compared to PC, the
resources are limited. we cannot support all of HTML5
... we want to profile our users to prioritize their needs
Masao: HTML5 is linked with the
hardware now. there are some common interfaces we need to put
together to decrease the burden on the enterprise side
... we need to get the priority from the customers
Kazunori: from ITU-T perspective,
we put together priorities
... HTML5 itself is a little delayed in launching into the
market
... depending on the organization, you might have different
prospectives
Florian_(Opera): HTML5 isn't a new platform. we don't have to spend thinking about what people wants, we already see what's theu're using
Florian_(Opera): if we don't provide it on the TV, they'll look somewhere else
scribe: people want the Web as it
is and if it can do more fine, but get them the Web first
... and then extend to do more
... best way to extend it is talk at W3C
Aaron_(Huawei): concerns about priorities: video is highest priority for us
Aaron_(Huawei): best interaction
scribe: very simple interaction
is our second requirement
... even email or twitter is advanced
... app store is also important
Toshiyuki_Maeda_(tv_asahi): in japan, broadcasting and telecommmunication convergence has has been a hot topic. displaying on the same screen isn't enough
Toshiyuki_Maeda_(tv_asahi): we need hyperlinks in broadcasting streaming and changing the display
scribe: with BML, it's already a
reality
... in BML, we're not satisfy it is done.
... BML can follow the speed of TV in terms of seconds
... if hyperlink is provided by broadcaster, people won't have
to go to their PC
Takara_Nakasone_(NTV): when it comes to tv perspective, in Japan, they are TVs that were sold more than 50 years ago
Takara_Nakasone_(NTV): but there is a gap in terms of web space
scribe: it's a challenge to
us
... I don't suppose we can replace tv sets every 2 or 3
years
... tvs are used for 10 years
Charles_(Opera): mobile phones in third countries is many years longer than in Japan or US
Charles_(Opera) there is a long upgrade cycle in computers as well
scribe: Opera runs on 15 years
old technologies
... like Windows 95
... Microsoft doesn't support this platform anymore
... there are strategies we can use to fill the gap
... it's possible to do upgrade in PCs, but not in TVs. why
not?
... we could build devices that will last
<kaz> s/scribe: if we don't provide/Florian_(Opera): if we don't provide/
Jan (Ericsson): on flash vs html5, how does it compare? are we keeping up?
Charles: Flash covers some video cases that I don't think we cover yet
<kaz> s/scribe: best interaction/Aaron_(Huawei): best interaction/
Charles: when Opera proposed
video in HTML in 2007, flash was there already
... how long will it have an advantage? probably one year
... flash and the Web are two entire technology stacks
... the Web is available on a much more wider set of
devices
... opera is making television that have access to the free Web
for years
plh: what about DRM?
Charles (opera): DRM clearly matters to the industry
scribe: most serious hard code
developers can't believe
... all DVDs ship with DRM, but they can still be copied
... all DRM can be broken
... but it has a value to the industry
... people still buy dvd
... I don't know why
... morally the right thing to do, more convenient, etc.
... HTML5 right now doesn't seem to have particular support for
DRM, I don't think it would make to include into HTML5
... it will get cracked
... it would make sense to look at the APIs around video
<jinhong> DRM issue on video, we remember music industry.
scribe: to make sure that they are DRM capable
<jinhong> also, HTML5 does not deal with DRM issues
scribe: the browser should know
that it can't play a video because of lack of rights rather
than network error
... the industry should go to the HTML needs to make their
requirements clear
... otherwise the group won't bother taking them into
account
Daniel Park (Samsung): DRM doesn't belong to user requirements, it comes from content owners
scribe: premiuin content on tv
has a different business content than the Web
... Web doesn't have premium content
... as of now
... imo, I'm not sure if W3C should deal with DRM or not in
HTML5
Hiroshi: talking to a company,
they told that protection is breached at some point or the
other. it will be compromise whatever you do
... this company is producing content btw
Charles: I don't think W3C is the
place to make DRM system
... it's not the place with the experts, and some of them think
it's a waste of time
... it's useful to go to W3C and tell them we'll use DRM in
video or application
... WAC, mobile app world, is looking into DRM
... also Ruppert Murdoch is planning that you're wrong, ie that
users will pay
Yoshitaka_Kasugai_(Microsoft): I'm in charge of silverlight and IE. DRM is a technology to encrypt content. W3C is a standard org, and there is no inconsistency between those two
scribe: you'll need acces to free and non-free content. for free content, you'll be able to use HTML5 for video content
?: I agree that W3C isn't the place to implement DRM, but you can mark some content that it cannot be saved
scribe: some optional headers or
marker
... you should be able to mark
... the content, for it to be protected
<Daniel> question to W3C: how and how protect contents on the Web ? by google ?
fukuno: I myself believe that DRM is related to ethics. people are interested in advanced app like twitter. should be able to "quote" video in order to talk about it
maeda: if there is a hyperlink on broadcast content, this would be more convenient
<Daniel> To Philippe, Well, in current situation, if DRM is protected to any contents by studios, you can't unfortunately. It's their compliance rule and very very strict...
maeda: if we can adopt html5, we can expect better presentation of the content
<Daniel> very serious talks are required to studio. I had these real experiences for several years.
Yosuke: in this group, there are
participants providing content for Web and others for TV
... Opera is interested in providing access to video
... within a Web page
... the way of offering between tv and web is very much
different
... maybe we can incorporate web content into the program so
users can visit the web through the program
... DRM doesn't have to be done by us, but if web on tv is to
offer premium content, we won't be able to avoid copyright
management
... otherwise we'll need to do something different
... if the algorithm from Microsoft is open, it could be
considered as a solution
Florian (opera): there is another issue: parental control. how is it similar to DRM? what should be done about it at the W3C level is probably similar to DRM.
scribe: we'll need to inform the Web browser why it was blocked
Charles (Opera): W3C has spent about 15 years on technologies to enable parental control. it's not interested in deciding what is appropriate or not
scribe: like POWDER
... it has been designed to provide a framework to apply
rules
Kaz: considering this session is about UI, I'm concerned about the current focus. if there is a need to have a device to control the screen from a distance
<inserted> ... some kind of AR technology might be also useful
Taisuke_Fukuno: I think you can
talk about many interface. very difficult to decide on one
format. we need an open technology.
... regarding parental control, if W3C can come up with some
kind of control...
Charles: it can be done
Masao (Microsoft): there is parent control in IE but it isn't well known.
<chaals> [IE has been implementing W3C parental control technology (allowng parents to decide what level they set for *their kids*) since IE 3.0 ...]
scribe: re interfaces, you can link various devices together
Kazunori: I think we need an
other perspective. in Afghanistan, there was a paper cover of a
woman with a damaged face, many shops didn't display the
journal
... everything on the Web isn't accepted on the TV screen
Oura_(Airframe): listening to the debate, tv and remote control device with one person watching, but many people are watching the same TV
scribe: you should be able to see
the information on the device in your hands.
... you can authorize content access based on age. so, the
terminals would hang under the TV screen
... several devices
... if W3C can define rules to create that kind of linkage
would be ideal
Daniel Park: I'm now really curious: parental control is a past issue on tv
scribe: watching tv all together
in living room
... would be valuable to have directions from w3c
Debbie: [summarizing]
... prioritirization of features, product cycles, flash/video,
DRM, premium content, parental control
... device format independent
... PC-TV hyperlinkage
... content appropriateness
... in the presentations, we heard a11n, useability, and the
general role of the remote
... any suggestion of key points?
Charles: we got distracted from
the topic: HTML5 for UI. it's an important topic. there is a
lot we can do with that
... Opera has been making TV UIs in HTML for years
Jan (Ericsson): we talked about HTML, what about SVG?
scribe: you might want to make it more interactive
Charles: when say HTML here, we
are really talking about the Web technology stack
... SVG was designed for phone, long before the iphone
Yosuke: if HTML5 is used for UI,
it's just a potential candidate. but web on tv has a lot of
issues
... is html5 truly the solution for all of the issues
... we cannot decide here
... html5 is one of the very powerful candidate
Debbie: thank you all for this session
→ 5-min presentaion x 4 (=20mins)
→ 70-min panel discussion including brief summarization of topics discussed during the session
katsuhiko: DLNA use cases
... Web portal site available on Hitachi's digital TV
... "Video de Mail" , email like video transfer app
... Message board, tags could be attached
... user needs?
... requirements for extensions:
... what kind of hardwares should be supported?
... resources?
... device control:
... reducing cost?
... collaboration with other CE devices
hiroyuki: Toshiba's digital TVs
are already BML ready (80%)
... What's Web, What's TV?
... TV was receiver of broadcasting services
... and getting "Hub in the home" for information
exchange
... TV as "Media Device"
<chaals> [use case of controlling other devices (air conditioner etc) is interesting...]
hiroyuki: new type of usage of TVs
... new type of contents
...technical topics: augmented reality, free-view TV
... points are:
... - new type of usages on TV as "Media Device"
... - new type of contents on TV for "Media Experience"
tatsuya: TV as device and Web as
services
... what do you do with TV?
... - watch movies, TV programs
... - play games
... - access Web services
... access to home-networked devices
... - existing standards available: UPnP, DLNA
... almost all TVs in Japan are DLNA ready
... UPnP is a framework for universal device connection
... DLNA is a guideline for interoperable connection
... interaction between Web apps and home-networked
devices
... - use case 1: recording TV program to networked recorder
based on EPG information
<jayy> do you think if home network issue is a scope?
tatsuya: - use case 2: networked
oven
... requirements:
... - functionality
... - versatility and extensibility
... - interoperability
... - security and privacy
Masaru: technicoror is former
Thomson
... provides set top boxes
... many DLNA certified devices have been deployed
... hybrd broadcasting
... on the other hand, users are getting confused because of
the tremendous amount of the contnets
... "2nd screen" as remote controller
... needs for UI/apps on CE platforms
... broadcasters want to keep control of content presentation,
etc.
... and, where should we go?
... we need an integrated platform
... open/flexible platform
... device agnostic
... bridge for home and Web
<jayy> who manage HGW?
Masaru: difference between "home gateway" and "TV"
yosuke: any question?
jan: question to the last presenter
masaru: TV as rendering device
could be located anywhere in home
... home gateway could be another device
jan: do you have any initial requirement for W3C?
masaru: not yet
matsuzawa: it's interesting to
have public APIs for TV as home-networked devices
... but it might be dangerous to control ovens etc. from
outside
... may be it should be OK to have private APIs?
katsuhiko: public APIs for ovens
etc. would be problematic
... so maybe the functionality should be restricted
... regarding the merit of providing that kind of APIs itself,
it could be useful for some people
hiroyuki: agree it could be
problematic
... and think we should make decision about guideline,
etc.
... however, defining template of public APIs would make
sense
... since it would be troublesome if those APIs are vendor
specific
tatsuya: agree with katsuhiko and hiroyuki about privacy, danger etc.
masaru: agree with others about
security and privacy
... regarding need for public APIs, it would be better for an
open eco system to involve various vendors to provide public
ones
charles: agree it would be
dangerous :)
... the fundamental point is communication between various
devices within home
... you can use geoloc info using your phone
... people working for specific devices should be
involved
... opera unite has a web server in a browser
... it could be the central controller
... you could standardize that
... regarding discovery problem, your web server has a specific
URI
... we already know privacy and security are important
... turning on air conditioner before my getting home could be
a nice use case
tatsuya: would like to
concentrate on positive side today :)
... we need to standardize technology to promote industry
more
masao_isshiki: has been working
for ECHONET, consortium for home network technology
... and would consider homenet/web integration
hiroyuki: agree it wouldn't be
great to define vendor specific APIs
... we would like to learn from the success of web apis
standardization
tatsuya: there are several
existing standardization works like DLNA and EHCONET
... and think universal approach is required
maeda: web on tv might be too
restricted
... "how to put broadcasting contents on TV device"
... for example we can see broadcasting contents using mobile
phones (1-seg)
... also we can access the Web using this mobile
... during the previous session, somebody said "HTML5 is
available on all the devices"
... but TV contents are also available
masaru: I also mentioned "2nd
display"
... both TV contents and Web contents are available on various
devices
... I'd let "2nd display" recorded in the note
katsuhiko: I think controlling home-networked devices could be a topic of device APIs
HwaKyung: canvas or CSS3 for
UI?
... richer capability of TV is enough with HTML5?
hiroyuki: requirements for
HTML5
... that's service dependent
... the current "HTML5" can do many things
... but getting events (process done) and changing processes
are not yet clearly defined
yosuke: regarding hardware resources?
tatsuya: we should clarify use
cases
... and start by describing the app you want and how to make
it, then think about what to do
... it's one of the merit we standardize something because it's
cost effective
... but this time, it would be better we consider use cases
first
hiroyuki: there would be
differences of performance between devices
... but Web technology should be scalable
HwaKyung: just want to remind use
cases are very important
... device performance is quite diverse
... we should consider not only the high-end devices
... but less powerful devices
Florian Rivoal
scribe: opera ships browsers for
less powerful devices (e.g., w/ 8MB RAM)
... It isn't necessarily very expensive to get full web
capability, and it is very expensive to try and build part of
the Web and then make enough applications that are good enough
to convince users to give up the full web they have and keep
buying the profile version
mike: disagree :)
... regarding TV, there is a long list of required features
(other than Web browsing)
... another point
... W3C do client side technologies
... not include device connection, negotiation like DLNA
... so we need to focus on that part (=client side software
technology)
jan: question to the panel
... DLNA/UPnP will be Framework for exchanging controlling the
protocol
... which W3C doesn't care
tatsuya: discovery should be
discussed
... but protocol could be anything, e.g., websocket, soap
... we're willing to have discussion
- Summarization
yosuke: peripheral devices for "Web on TV"
tatsuya: not only "peripheral devices" but also independent devices
yosuke: this was mentioned by hiroyuki
<chaals> [Agree with Tatsuya that thinking as if the TV is *the* centre, and everything will revolve around that, isn't a good way to make sure we are looking carefully at the real world]
yosuke: (continue to review the topics from this session)
<chaals> [(because if TV doesn't do a good enough job, then it will stop being part of the home network...)]
[ yeah, I think multimodal architecture is kind of related to that idea :) ]
yosuke: security and
privacy
... (flexible) framework for exchanging information
... second screen
... HTML5 profile for devices
tatsuya: "profile" should be split into two topics: 1. pick up several features and define a new set and 2. selecting several features and define a sub set
jan: like the word
"profile"
... which is the minimum "profile" for devices?
Florian: time spent creating profiles that restrict which part of HTML can be use will only result in loss of compatibility with the existing web. This destroys more value than it saves cost.
mike: defining "profile" is not
the bible of W3C
... it has been very painful to define profiles
... profiling takes years
... device capability improves faster than the standardization
work
... it's not easy to define profiles
HwaKyung: my question is
... W3C should consider people who owns web services
... many TVs with various performance
... W3C should consider accessibility for them
ph: we have done profiling for
mobile web activity
... two mobile profiles
... there were many similar discussions when we did mobile
profiles
masaru: regarding profiling
... requirements should be defined based on the needs of
contents providers and users
katsuhiko: we've never experienced "Web on TV" (=let Web apps work on TV device)
<chaals> [We have experienced Web apps working on TV devices at Opera]
katsuhiko: so would expect we can start nice discussion from now
→ 5-min presentaion x 4 (=20mins)
→ 70-min panel discussion including brief summarization of topics discussed during the session
kim: overview
... QOOK TV
... - Brand name KT's IPTV
... - About 1.6 million subscribers
... - Based on DVB standards
... - a Walled Garden service
... - not so popular as in japanese DTV services
... - market decide the killer service; openness is
important
... Plans to "OPEN"
... - Java developers or community in korea is so small
yang: Requirements to "WEB on
TV"
... We're exprecting,
... - TV Functions on WEB
... - To prepare web ... application market
... -- displaying something is not enough. more fuctionality or
rich contents needed.
... - Interfaces for various external functions
daniel_park:
Kim: (oops write down later :yosuke. )
leonard: Leonard Chin (Dwango)
... demo
... scrolling texts on video (niko-niko douga)
... use cases for a Future of tv
... - Audience-Performer Interaction
... - Shared Viewing Experience
... - End-to-End
... - Ubiquitous Television
... Any one can broadcast television.
... Requirements
... - requirements for pre-recorded TV listed
... - requirements for streaming TVisted
... standard for Video missing
... Live Streaming Requirements
... - require near real-time latency for efficient
communication
Issues: Microphone/Camera
... Issues: Encoding and Codecs
... - H.264 licensing problem
Takashi_Matsuzawa(Myriad): not
question, but only a comment
... relationship between video and TV
leonard: we think essentially there
is no difference with video and TV
... so they should be integrated in the future/
yang_kaist: use cases of device APIs for Web on TV
<Daniel> adding translation's missing part: TV should be considered and open for 3rd party application developers
yang_kaist: Requirements of
Device APIs for Web on TV
... - Current DAP and Device APIs for Web on TV
... - Standardization for SmartTV
... Use cases of UI/UX for Web on TV
... Requirements of UI/UX for Web on TV
... - HTML5 / CE-HTML is appropriate for Web on TV
... - Desgin principles for TV Applications.
<Daniel> missing part from translation: MobileOK came from MWI, and that activity seems very useful for mobile markets. Can be useful information to TV market
jun: canon is an imaging device
company.
... SVG
... - Canon cares Image Quality
... - Scalability is the Key to support Higher Res.
... - W3C SVG Working Group
... Device APIs
... - Canon Devices are Input & Output Devices
... - Hyperlinking is the Key to Connect Devices
... - Device APIs should not be limited to Smartphones
... -- Open Web Platform (esp. using Hyperlink)
... Web on TV
... - Should support Rich User Interface
... - Should allow Web applications to handle media contents
directly from/to devices.
jan: what kind of link?
jun: specifying device info using forms etc.
philipp: any questions from audience to canon?
donyoung(LG): mechanism for device connection?
jun: devices include
Web server capability
... but would think about nicer mechanism
ph: (go through the topics recorded on the flipchart)
jan: asks about APIs to manage applications
kim: application life-cycle management issues is very important.
kaz: mentions MMI
Architecture spec (http://www.w3.org/TR/mmi-arch/#EventExamples)
... might be one of the candidates for device management
<ddahl_> the MMI Architecture would especially apply to devices that capture and react to user input
matsuzawa: optimization?
jun: there are several examples of content optimization for Web, e.g., CSS
matsuzawa_miriad: comment:
optimized retrieval of application
jun: think it would be more productive to focus on how to apply Web technology to devices
charles: an application
could work nicely for powerful devices but should work for less
powerful devices
... application developers should be the ones who decide how to use the
expression capability of each cousumer devices
... we can use existing
Web technology for scalable apps
... and then choose the best one.
<kaz> (discussion between jan and charles)
someone: how applications lookup device specs or capabilities.
ph: (mentions Device APIs WG and wonders about what kind of APIs should be discussed here)
charles: should start
with use cases
... changing channels, etc.
<Florian> [user agent sniffing is possible, and useful in certain cases. But it should be used with care: because of the huge variety in devices, it doesn't scale very well. Capability detection, media queries, etc, scale much better. Check what the device can do, not which device it is]
charles: program guide
<kaz> (APIs for what?)
jan: (if it's defined
within W3C) the APIs should be open
... from the view point of TV and STB, what kind of API will be
needed by these devices.
<kaz> (jan: video tags for HTML and SVG, etc.)
mike: APIs should be language independent
... you should be using Web IDL
... generic APIs
jan: Yes, we looked at converting what we have to Web IDL. SHouldn't be too hard, but we haven't done it
florian: would make lot
of sense to add APIs for EPG, channels, etc.
... who write down the spec doesn't matter. mutual reference is important.
kawamori: about EPG API
... if you use HTTP, you can get any data
... do we really need that specific API for TV terminal?
... we don't need very complicated API
charles:
we should start with use cases, not start with API
... then think about what is missing
<jinhong> I agreed charles, but this meeting the service providers are not many participated.
jan: extract program information from broadcast signals. (in the situation no ip connectivity)
<kaz> kawamori: we have to be clear about what sort of use cases we have
jan: an example from satelite broadcasting
<kaz> kawamori: if hybrid usage is an actual use case, it's ok
someone: usecase is already discussed a lot. why more use cases needed?
<kaz> nobuo: why use case again??? shouldn't we move ahead?
<kaz> ph: we discussed use cases on several (different) topics so far
<kaz> nobuo: W3C once discussed "video on web" several years ago
<kaz> ... and this workshop is dedicated to "Web on TV" (or rather "Web and Web"
<kaz> ... just thinking about use cases would not make much sense, would it?
<kaz> ph: thanks for your comments
<kaz> HwaKyung: in mobile, there are various specs
<kaz> ... W3C could be a stream line of those specs
<kaz> ... we're in confusing situation
someone: conflict exists in many situation, web services, degital broadcasting etc.
<kaz> ph: any more comments?
<kaz> yang: agree with HwaKyung
ph: summarizing in last 10 min.
<kaz> yang: putting use cases together is important
<kaz> ... devices could be connected to TV using DLNA etc.
<kaz> ... we could compile use cases and define APIs
<kaz> charles: compiling use cases is important
yang: gathering use cases makes sense for designing device APIs
<kaz> ... on the other hand, I think Saito-sensei (nobuo) is correct
<kaz> ... we've already got many use cases
<kaz> ... the goal is not just collecting use cases
<kaz> ph: would summarize the discussion
<kaz> ... (reviews the list of topics)
ph: session finished.
<kibuhm> "Java developers or community in korea is so small" is translation miss
<kibuhm> in korea there are large number of JAVA community and developers
<kibuhm> MHP family application developers and community are small, even through MHP family middleware is based on JAVA
→ during the break, held a vote on use cases/requirements from the previous sessions so that we can prioritize use cases and identify potential new languages and language extensions
We asked all the attendees to nominate a representative from each organization, and asked the representatives to vote on their preferred use cases/requirements using five colored stickers. To see if there is any difference between the preference of W3C Members and non-Members, Member companies used green stickers and non-Members used yellow stickers.
<Dewa> I believe just Java developer can't write MHP application instantly, but the study curve is low. Do you know what is the reason why MHP developper community is small?
<kibuhm> Because of huge numbers of Java extension APIs
<kibuhm> and
<kibuhm> hard to test
<kibuhm> only It is possible on the STB(or CE devices)
<Dewa> Yes, I know about many extensions and I agree with hard to test for MHP application. Thanks.
<Dewa> That is to say, development of MHP application is not good cost balance for TV business?
<chaals> or people are not developing applications for TV?
<kibuhm> TV application market in Korea is so small
<kibuhm> so developers have little interests
<Dewa> Understood.
<kibuhm> I think that If the number of web device APIs are huge in Web on TV, the situation are same as MHP
- synch between broadcasting and Web Services: 6 green and 5 yellow
- personalization: 6 green, 2 yellow
- usability/accessibility: 6 green, 1 yellow
- API between TV and remote: 11 green, 9 yellow
- diaster/emergency information: 4 green, 2 yellow
- DRM (Digital Rights Management) in HML5: 3 green and 4 yellow
- hyperlink in video content: 8 green, 4 yellow
- content linkage between PC and TV: 4 yellow
- role of SVG: 4 green
- peripheral devices for Web on TV devices: 4 green
- interaction between web apps and home network devices: 4 green, 8 yellow
- security: 3 green
- control for home network devices: 2 greens, 3 yellow
- second screen: 5 yellow
- Opening TV to web / web apps: 3 green, 2 yellow
kaz: everyone is interested in
API's between TV and remote, personalization and
accessibility
... what is the next step?
... goal of workshop is to idendtify key use cases and
requirements, new standards, impediments in current
standards
... i believe we need a new WG and generate dedicated
specifications
... the audience includes broadcasters, service providers,
device vendors, and software vendors
... we heed a charter and scope. participants must be W3C
members, and we need a Chair or co-chairs
... who is interested in WG?
fujisawa: first clarify what kind of work is involved before asking who is interested
kaz: who is interested in the
initial group?
... all the topics we have discussed today?
... we don't want to stop the momentum
fujisawa: what you are suggesting here in terms of the Web on TV, are you trying to launch a WG? there are so many interesting use case, there might be a high level activity with several WG's
kaz: that is a great question. we haven't identified the scope yet, we could have separate WG's for different topics, first we write the charter and then start the WG
kim: we had video on Web WS a few years ago, and we had several WG's coming from that, we have to decide this first
chaals: deciding to start a WG is
too quick, there is clear interest on several topics, we need
to disseminate the results to the rest of the W3C and the TV
community
... we could also have an IG, with some amount of time to
identify the things we're working on, then we can propose
charters
... some ideas don't need a separate WG, work would go in in
existing WG's
... would be more useful to start an IG to get started
kaz: would like to ask the audience how to proceed, start an IG, send topics to existing WG's
???: we could vote, we could start a group for items that attracted a lot of voting
kaz: we could think about who is
interested in which topics
... what kind of topics could be discussed in greater
detail
funahashi: we could start up IG
or WG, we are speaking sometimes in different languages because
we come from different domains
... the topics could be distributed to different WG's and this
would promote understanding among people from different
domains.
... there are some topics that we haven't reached understanding
on.
... we could specify more interesting points later.
kaz: there are several options, IG, multiple WG's
daniel: there are a little more
than 100 people with many interests, we should have a very
concrete proposal for moving forward.
... prefer to create a WG, IG would be too time-consuming. the
main goal of a workshop is to make a decision for moving
forward.
... would like to have a clear direction (this is an official
comment from Samsung)
???: why don't we we think about forming an IG first, and we can invite non-members, if they have to join W3C first, it might take a long time to make the decision.
scribe: WG is not suitable for the long term interest of this group
chaals: agrees with Fujisawa-san, it's important for non-members to join the discussion, and joining the W3C and WG is time-consuming .
the IG should be explicitly chartered to look at the things that have come from this workshop as important, should have a time limit of 3 months
scribe: this would make sure that
we have the right participants
... it's also useful to maintain an IG as a place for more
general discussion and to help disseminate the work of
WGs
... this is Opera's official position
mikeSmith: even more lightweight option would be to set up a mailing list
chaals: we do need to do this
work and I do want to move forward. we should set up a mailing
list by all means.
... we can discuss this on mailing list and in IG before we
jump into making a decision
Narm(Intel): representing Intel, would like to ask about how Touch WG was formed.
phl: the Touch WG is under review, it hasn't been created yet, the current charter was done after several negotiations, it was not done from a workshop.
ph: there are quite a few ways to
create groups, one is to have a workshop and see what the sense
of the workshop is, then a mailing list is created, there's
some discussion, and someone comes up with a charter.
... then after discussion, the proposal is sent out to the
whole W3C membership. this discussion is an important part of
the process.
... scope is an important part of the discussion, we could come
up with some items today,
... that is an important part of the process
kaz: a question for non-members? are any of you interested in becoming members? Sony, NHK, television guys?
???: we can't decide now, I can't make that decisinon now. providing content that users want is important, but DRM is very important to us.
scribe: section 2-2 and 2-6 talks about DRM, so those tallys should be combined.
mkeSmith: the fact of this
workship is an indication that W3C is very interested in this
topic.
... we have new CEO from Novell, who has a solid industry
backgound, we are working on aligning with industry needs and
market needs.
... the way that these decisions get made is through people
within organizations socializing the W3C.I will be happy to
come at any time.
lee: from LG, our position is that we don't object to making a WG and we would probably join, if we don't have a clear idea we should have an IG first. we should limit the IG to 2 or 3 months.
habu: (Allied Resources) we would
be interested in joining the W3C and a WG, but not if there is
no clear direction. TV now has a lot of standards, some haven't
gotten much attention.
... already in BML there is an API for broadcasting, we should
look at existing standards and follow up on those. that would
decide on the scope and be useful in considering the scope.
<chaals> [+1 to looking at existing approaches as a useful activity to getting a clear scope quickly]
jan: the open activitiy forum
believes in DRM and would invite Japanese broadcasters to look
at our use cases.
... it is open, please look at our requirements.
chaals: W3C doesn't not believe in DRM
Nobuo_Saito: in the discussion of IG vs. WG, both can be started, IG could deal with accessibility and DRM. is it correct that non-members can participate in IG?
kaz: we have an invited expert process, but it is getting more and more difficult to get approval for that. it is true that we can start both IG and WG
yosuke: in order to produce some
results in an IG we should give some due date, like 2-3
months
... globally we have much more participation we have to come up
with a charter of global interest. getting people together and
expressing opinions doesn't lead to progress.
... we have to start some project, or we won't produce any
results. we can have the IG and WG established together. if we
need taht we need to estabilish goals first, that will lead to
nowhere.
daniel: how much real
implementation can we open during an IG discussion? in this
room most people are from Asia, but all W3C was invited.
... we have to make a clear direction for that activity. our
conclusion today must be official.
... if we can make our decision to make a WG, lack of
participation from other countries is not a problem.
kaz: we can ask participants
about IG, WG, XG, or mailing list options, then consider some
concrete timeline.
... the first possibility is a WG; who is interested in forming
a WG on Web on TV topics?
florian: the confusion now is why we need an IG, we're confused about the scope of a WG.
chaals: Opera is interested in the work, but would like to see a charter before committing to a WG.
kaz: 40 people are interested in
an IG
... timeline?
???: (Intel) is this vote just for members or is the vote one per company?
kaz: I think 40 people interested should be ok
plh: I see a lot of interest in the
API between the TV and the remote, maybe would fit into Device API
work, maybe the hyperlink in video can fit into existing video
in the Web Activity.
... I invited individuals who are interested in hyperlinks in video to contact me./
kaz: another option is fitting into existing groups
Nobuo_Saito: whether to form IG that still requires a charter, so maybe need to identify a representative from each country to develop a charter for IG, and then we ask members if they want to join that.
scribe: let's identify representatives and ask them to form a charter
kaz: we need a charter even for an IG
kaz: IG can provide input to other groups, as a conclusion, we can form an IG and they can provide input to other WG's
chaals: we request W3C to form an
IG in this area and that IG may lead to WG's.
... IG should be as fast as possible within W3C process
kaz: conclusion is to bring this to W3C
ph: we need someone to write a charter and to chair the IG, please let kaz know
<chaals> [I volunteer to help draft a charter (but will not chair)]
kaz: who is interested in chairing?
<chaals> [Funahashi-san volunteers!!]
kaz: yosuke
???: I think we should form a WG now, too.
scribe: for some of the topics
that are clear.
... we need to have a charter and we need to think about
members who aren't present, but we can start a WG from any
items that we're clear about.
... we should start from IG first
kaz: there are some very much preferred topics, where existing WG's are working. it will facilitate the process if the IG starts.
???: a concrete timeline, like February or November for a face to face meeting
chaals: volunteered to write
charter, but it takes at least 1-2 months from now to have the IG
formally chartered and running, an informal mailing list could
start early next week.
... a WG takes longer
jan: what about the proposed European workshop? Will that be an IG meeting?
ph: we haven't confirmed that workshop, IG or WG could have a workshop, but people in Europe may want to join sooner.
<chaals> s/1-2 months/1-2 months from now to have the IG formally chartered and runnun/
jan: in the European workshop we could consider more use cases or refine use cases.
chaals: if there is a workshop in Q1 next year it will be far from finished. Opera would still be interestedin participating.
s/interestedin/interested in
<chaals> s/a WG takes longer/a WG will probably take until about Christmas to develop/
daniel: do we have to submit a position paper again?
dong-young: I would like to make it clear that the IG is just to identify the work and it should be done as soon as possible.
kaz: by Christmas, a few months.
dong-young: three months is acceptable, but the shorter the better.
chaals: 3 months is the time it takes to charter and get participants signed up, 3 months is realistic
omata: what is the action plan? only mailing list
kaz: maling list can be created
Monday or Tuesday, but IG or WG takes longer, need to follow
process, need charter and official proposal. it is impossible
to do it in two weeks.
... we need to make a mailing list and continue talking.
HyeonJae_Lee(LG): possible IG chairs are Funahashi-san and
Kawamori-san
... would like to have yet another co-chair from browser company?
Kaz's note: Though not clearly recorded in the minutes, HyeonJae Lee from LG also volunteered to be a candidate co-Chair for the expected TV IG.
chaals: Opera is already providing many chairs, so there is a limit, we will participate, however
funahashi: about the timeline,
everyone seems to agree on Christmas as a goal, of course we first
have to come up with an IG charter.
... in two weeks we
will have the minutes of the workshop, so by the end of September
we will have the schedule and the process plan for making the
charter. We will look at the socpe of three months and do as much
as possible.
omata: for the non-members, what is a charter?
<plh> http://www.w3.org/2010/webapps/charter/
<chaals> charter ~= statement of work
kaz: you create a charter to
explain the purpose of the IG or WG, all the 70 WG's and IG's
have written charter describing their work.
... who is going to be the chair, the staff contact,
activities, specifications, material that they're going to use
in the specificaiton.
isa: today's decision to establish an IG is to talk about the items that have been mentioned and organize the ideas, is that right?
kaz: the two co-chairs will
discuss how to continue with that.
... thanks to everyone that was a wonderful discussion.
(adjourned)
<yosuke> s/have a charter proposal/have the shedule and the process plan for making the charter/
kaz: to confirm, the two people who volunteered to co-chair the IG are Funahashi-san and Kawamori-san, and Chaals volunteered to write the charter.
The Call for Participation, the Logistics Information, the Presentation Guideline and the Summary are also available on the W3C Web server.
Masao Isshiki, Michael Smith, Deborah Dahl and Kazuyuki Ashimura, Workshop Organizing Committee
$Id: minutes.html,v 1.52 2010/12/08 06:00:39 ashimura Exp $