Re: Some comments

Dear Futomi:

Thanks for the work and I have a quick question.

Section 7, it seems you listed SVG-based page as a "requirement". Is 
there a practical reason for requiring so? I feel okay with SVG as an 
option ('MAY' instead of 'MUST') but a requirement I believe will add 
unnecessary complexity to players as SVG may be an overly complicated spec.

Just wanted to understand the logic behind your thinking.

John C. Wang
IAdea: Digital Signage Media Appliances
http://www.IAdea.com
Skype: jcwang_tw

On 5/23/2013 10:03 AM, Futomi Hatano wrote:
> Hi all,
>
> I updated the doc as a result of the discussion in this thread.
> http://futomi.github.io/Web-based_Signage_Player_Core_Profile/
>
> * Delete the phrase mentioned abut PDF from "Single image"
> * Replace the term "content viewport" with "application viewport"
>
> You can see the changes in detail here.
> https://github.com/futomi/Web-based_Signage_Player_Core_Profile/commit/fdf8e989068fdec4460da218de9d03684282d909
>
> Besides, I added "Scheduling Profile" as a planned profile on the wiki.
> http://www.w3.org/community/websignage/wiki/Main_Page#Profiles_for_Web-based_Signage_Player
>
> Cheers,
> Futomi
>
>
> On Thu, 23 May 2013 09:50:11 +0900
> Futomi Hatano <futomi.hatano@newphoria.co.jp> wrote:
>
>> Hi Franck,
>>
>>> 7 Scene content types
>>>
>>>> I know PDF is *not" identical to an image file.
>>>> But in terms of HTML, PDF is conceptually similar to an image file
>>>> because the img element in a HTML document is allowed to
>>>> embed an PDF file in itself.
>>> I am not agree. PDF must be see like a document and not like an elementary media (image or video).
>>> PDF can contain jpeg, font, signature, stamp, mp3, forms like a HTML page.
>>> For example, our player (Playzilla) treat PDF like a HTML page with “PDF.JS” inside a iframe.
>> Good point. It makes sense.
>> Maybe, we see PDF in a different way.
>> You see it in terms of its structure.
>> I see it in terms of authoring.
>> (Authors can treat the both in a same way using the img element)
>> Anyway, it seems to be confusing if PDF is put in "Single image".
>>
>> The following phrase seems to be deleted from "Single image".
>> [[
>> Players may support more sophisticated formats, such as PDF. [PDF]
>> ]]
>>
>> Cheers,
>> Futomi
>>
>>
>>
>> On Wed, 22 May 2013 22:32:32 +0200
>> "Franck Dupin" <franck.dupin@innes.fr> wrote:
>>
>>> Hi Futomi,
>>>
>>>   
>>>
>>> My comments about your comments :
>>>
>>>   
>>>
>>> 6 Regions
>>>
>>> …
>>>
>>> sorry, I did not read
>>>
>>>   
>>>
>>> 7 Scene content types
>>>
>>>   
>>>
>>>> I know PDF is *not" identical to an image file.
>>>> But in terms of HTML, PDF is conceptually similar to an image file
>>>> because the img element in a HTML document is allowed to
>>>> embed an PDF file in itself.
>>>   
>>>
>>> I am not agree. PDF must be see like a document and not like an elementary media (image or video).
>>>
>>> PDF can contain jpeg, font, signature, stamp, mp3, forms like a HTML page.
>>>
>>> For example, our player (Playzilla) treat PDF like a HTML page with “PDF.JS” inside a iframe.
>>>
>>>   
>>>
>>>   
>>>
>>>> As you mentioned, PDF have the slideshow mode. On the other hand,
>>>> GIF can have similar capability using animations (i.e. animation GIF).
>>>> I think that having the slideshow mode is not a matter in this context.
>>>   
>>>
>>> Why not, but GIF is an elementary media not a document.
>>>
>>> W3C describes very well the kinds compound documents CDF by inclusion (pdf, epub, ms-powerpoint,..) and CDF by reference (HTML, RSS feeds,…)
>>>
>>>   
>>>
>>>   
>>>
>>>> The document is "Core Profile".
>>>> As described in the section "Abstract",
>>>> it defines just requisite minimum for web-based signage.
>>>> Most of existing signs don't need all features.
>>>> We can define other features as other profiles.
>>>> Actually, this BG has listed some profiles in the wiki.
>>>> <http://www.w3.org/community/websignage/wiki/Main_Page#Profiles_for_Web-based_Signage_Player> http://www.w3.org/community/websignage/wiki/Main_Page#Profiles_for_Web-based_Signage_Player
>>>   
>>>
>>> Right.
>>>
>>> But my point of view is that it is questionable to support “PDF format” in the core profile.
>>>
>>> why not consider it in a more complete profile?
>>>
>>>   
>>>
>>>   
>>>
>>>> 8 Playlist
>>>> …But the "Core Profile" doesn't treat media files such as video, audio.
>>>> Video and audio are planed to be defined in the "Basic Media Profile"
>>> Right.
>>>
>>>   
>>>
>>>> 9 Scheduling
>>>>> Why don’t advice full features of  iso8601
>>>>> ( <http://en.wikipedia.org/wiki/ISO_8601> http://en.wikipedia.org/wiki/ISO_8601) :
>>>   
>>>
>>>> Though the documents we are planning don't define the format,
>>>> It seems to be really helplul. I didn't know it.
>>>   
>>>
>>>>> Repeated Date/Time Events with some examples :
>>>>> On the top of every hour starting 9AM on January 1st, 2010
>>>>> R/2010-01-01T09:00/PT1H
>>>>> On midnight of each of the first 6 Mondays in the year 2010
>>>>> R6/2010-01-01+w1/P1W
>>>   
>>>
>>>> It seems to be useful.
>>>> How about we plan to make "Scheduling Profile" or
>>>> "Scheduling Extension"?
>>>   
>>>
>>> Scheduling Profile : Indeed it would be a good idea
>>>
>>>   
>>>
>>>   
>>>
>>> Sincerely,
>>>
>>>   
>>>
>>> Franck Dupin
>>>
>>>   
>>>
>>> Description : logo-innes
>>>
>>> ZAC Atalante champeaux
>>>
>>> 5A rue Pierre Joseph Colin
>>>
>>> 35000 RENNES - FRANCE
>>>
>>> Tel: +33 (0)2 23 20 01 62 / Fax: +33 (0)2 23 20 22 59 / http://www.innes.pro
>>>
>>>   
>>>
>>>   
>>>
>>>   
>>>
>>>   
>>>
>>>   
>>>
>>>   
>>>
>>>   
>>>
>>>   
>>>
>>>   
>>>
>>>   
>>>
>>> -----Message d'origine-----
>>> De : Futomi Hatano [mailto:futomi.hatano@newphoria.co.jp]
>>> Envoyé : mercredi 22 mai 2013 03:22
>>> À : franck.dupin@innes.fr
>>> Cc : public-websignage@w3.org
>>> Objet : Re: Some comments
>>>
>>>   
>>>
>>> Hi Franck,
>>>
>>>   
>>>
>>> Thanks for your helpful comments.
>>>
>>> Responses inline below.
>>>
>>>   
>>>
>>> On Tue, 21 May 2013 23:07:07 +0200
>>>
>>> "Franck Dupin" < <mailto:franck.dupin@innes.fr> franck.dupin@innes.fr> wrote:
>>>
>>>   
>>>
>>>> Hi Futomi.
>>>> Thanks a lot for your work about web signage player.
>>>> I have some comments about your document proposal
>>>> ( <http://futomi.github.io/Web-based_Signage_Player_Core_Profile/> http://futomi.github.io/Web-based_Signage_Player_Core_Profile/) :
>>>> 4. Concept of viewport
>>>> “The display viewport is the area in which the display can show something.
>>>> The content viewport is the area in which an application shows
>>>> web-based signage contents. The display viewport and the content
>>>> viewport are not necessarily identical.”
>>>>> I’m bored with your notion of “content viewport”. in fact, you
>>>>> describe
>>>> here an “application viewport”. “application viewport” being composed
>>>> of a region(s), of a scene, of a content like your illustration
>>>   
>>>
>>> You are right.
>>>
>>> The term "content viewport" is likely to be confusing.
>>>
>>> The term "application viewport" seems to be better.
>>>
>>> I'll modify it soon.
>>>
>>>   
>>>
>>>> 6 Regions
>>>> “Background color
>>>> This color will be seen at areas where the contents do not exist or
>>>> the contents are transparent. This color is specified in a CSS color.
>>>> [CSSCOLOR]”
>>>>> You talk about background color for regions but can we consider
>>>>> background
>>>> color  for content viewport ( and display viewport) ?
>>>   
>>>
>>> Yes.
>>>
>>> This document has already included the background color for both of the content viewport (a.k.a. application viewport) and the display viewport.
>>>
>>> See the section "5 Viewport properties".
>>>
>>>   <http://futomi.github.io/Web-based_Signage_Player_Core_Profile/#viewport_properties> http://futomi.github.io/Web-based_Signage_Player_Core_Profile/#viewport_properties
>>>
>>>   
>>>
>>>   
>>>
>>>> 7 Scene content types
>>>> “Conformant players of this profile must support 3 types of contents as a
>>>> scene.
>>>> Single image
>>>> Players must render an image file as a scene. Players must support PNG, GIF
>>>> (including animation gif), and JPEG as an image format at least. An image
>>>> file is rendered using the img element or the object element specified in
>>>> HTML5. [PNG] [GIF] [JPEG] [HTML5]
>>>> Players must support DataURLs for images. [RFC2397]
>>>> Players may support more sophisticated formats, such as PDF. [PDF] “
>>>>> I think it is an error to consider pdf document like single image. Pdf is a
>>>> CDFi (Compount Document Format by Inclusion – see
>>>>   <http://www.w3.org/2004/CDF/> http://www.w3.org/2004/CDF/) and specifically “paged document” with
>>>> slideshow mode
>>>   
>>>
>>> I know PDF is *not" identical to an image file.
>>>
>>> But in terms of HTML, PDF is conceptually similar to an image file
>>>
>>> because the img element in a HTML document is allowed to
>>>
>>> embed an PDF file in itself.
>>>
>>>   
>>>
>>> As you mentioned, PDF have the slideshow mode. On the other hand,
>>>
>>> GIF can have similar capability using animations (i.e. animation GIF).
>>>
>>> I think that having the slideshow mode is not a matter
>>>
>>> in this context.
>>>
>>>   
>>>
>>>   
>>>
>>>>> A signage player should play :
>>>>> Image raster (png, gif, jpeg)
>>>>> Vector (svg, svg+smil, flash)
>>>>> Video (mp4, webm)
>>>>> HTML5 based page (iframe)
>>>>> Paged document like pdf, e-pub,  or ms-powerpoint / open office documents
>>>> ( <http://webodf.org> http://webodf.org )
>>>>> RSS / Ticker / Why not Timed Text ( <http://www.w3.org/AudioVideo/TT/> http://www.w3.org/AudioVideo/TT/ or
>>>>   <http://dev.w3.org/html5/webvtt/> http://dev.w3.org/html5/webvtt/ )
>>>   
>>>
>>> The document is "Core Profile".
>>>
>>> As described in the section "Abstract",
>>>
>>> it defines just requisite minimum for web-based signage.
>>>
>>> Most of existing signs don't need all features.
>>>
>>> We can define other features as other profiles.
>>>
>>> Actually, this BG has listed some profiles in the wiki.
>>>
>>>   <http://www.w3.org/community/websignage/wiki/Main_Page#Profiles_for_Web-based_Signage_Player> http://www.w3.org/community/websignage/wiki/Main_Page#Profiles_for_Web-based_Signage_Player
>>>
>>>   
>>>
>>> What we should discuss now is what features should be
>>>
>>> included in the Core Profile or not.
>>>
>>> I don't want the Core Profile to be overengineer.
>>>
>>>   
>>>
>>>   
>>>
>>>> 8 Playlist
>>>> “…Each scene must have the duration. If the duration isn't specified,
>>>> application is encouraged to adapt the default duration (for example,
>>>> 60seconds).”
>>>>> Sequence can have indefinite duration because intrinsic media duration
>>>> (video or rss after unknown flow of items)…
>>>   
>>>
>>> Right.
>>>
>>> But the "Core Profile" doesn't treat media files such as video, audio.
>>>
>>> Video and audio are planed to be defined in the "Basic Media Profile"
>>>
>>>   
>>>
>>>   
>>>
>>>> 9 Scheduling
>>>>> Why don’t advice full features of  iso8601
>>>> ( <http://en.wikipedia.org/wiki/ISO_8601> http://en.wikipedia.org/wiki/ISO_8601) :
>>>   
>>>
>>> Though the documents we are planning don't define the format,
>>>
>>> It seems to be really helplul. I didn't know it.
>>>
>>>   
>>>
>>>>> Repeated Date/Time Events with some examples :
>>>>> On the top of every hour starting 9AM on January 1st, 2010
>>>>> R/2010-01-01T09:00/PT1H
>>>>> On midnight of each of the first 6 Mondays in the year 2010
>>>>> R6/2010-01-01+w1/P1W
>>>   
>>>
>>> It seems to be useful.
>>>
>>> How about we plan to make "Scheduling Profile" or
>>>
>>> "Scheduling Extension"?
>>>
>>>   
>>>
>>> Cheers,
>>>
>>> Futomi
>>>
>>>   
>>>
>>> --
>>>
>>> Newphoria Corporation
>>>
>>> Chief Technology Officer
>>>
>>> Futomi Hatano
>>>
>>> --
>>>
>>>   <mailto:futomi.hatano@newphoria.co.jp> futomi.hatano@newphoria.co.jp
>>>
>>>   <http://www.newphoria.co.jp/> http://www.newphoria.co.jp/
>>>
>> -- 
>> 株式会社ニューフォリア
>> 取締役 最高技術責任者
>> 羽田野 太巳 （はたの ふとみ）
>> futomi.hatano@newphoria.co.jp
>> http://www.newphoria.co.jp/
>>

Received on Thursday, 23 May 2013 04:36:05 UTC