RE: Some comments

Hi all

I share the point of view of Futomi.
For example, in Playzilla (our player), the control data is a smil file (CSS3 + JS with more) .
HTML5 and SVG are content type.
Attention: We were taken to manage an AppCache file in addition to the control data file. This notion is not specified in the paper. I do not know if this should be the case. John, have you had the same need in your "offline" smil player?

Concerning SVG in the core format, I understand the opinion of john in the case of a box or display  with old ARM processor. But the evolution of processors today bring minimum of html5 with SVG, Canvas, etc ...
For example new Samsung Smart Signage Large Display support a complete HTML5 stack (http://www.samsungdforum.com/Devtools/Spec). Spinetix too, maybe Brightsign ....


Sincerly,

Franck Dupin
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 : John C. Wang [mailto:John.Wang@IAdea.com] 
Envoyé : vendredi 24 mai 2013 06:01
À : Futomi Hatano
Cc : public-websignage@w3.org
Objet : Re: Some comments

Agreed.

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

On 5/24/2013 11:59 AM, Futomi Hatano wrote:
> Hi John,
>
> I think SMIL is a kind of the playlist formats rather than a content type of a scene.
> In the doc, it is called "Control data".
> See the section "3 Concept of control data".
> http://futomi.github.io/Web-based_Signage_Player_Core_Profile/#concept
> _of_control_data I know SMIL is common in the signage industry, so I 
> intentionally didn't define the format of the control data in the doc.
> We can use SMIL as the format of the control data.
> (though someone has to develop a parser of SMIL as a JavaScript 
> library)
>
> Cheers,
> Futomi
>
>
> On Fri, 24 May 2013 11:38:05 +0800
> "John C. Wang" <John.Wang@IAdea.com> wrote:
>
>> Hi Futomi:
>>
>> Thanks for the consideration. I don't think there is too many companies using SVG, but many may be using SMIL (see http://www.a-smil.org/index.php/SMIL_systems for commercial digital signage products), which shares a subset in the animation portion with SVG. However, I feel it would be highly controversial if we include either one as REQUIRED by the Core Profile.
>>
>> Personally I'd recommend listing SMIL as an "option" in light of the large number of supporting software options.
>>
>> John C. Wang
>> IAdea: Digital Signage Media Appliances http://www.IAdea.com
>> Skype: jcwang_tw
>>
>> On 5/24/2013 10:40 AM, Futomi Hatano wrote:
>>> Hi John,
>>>
>>> Thanks for your comment.
>>> It's a good question!
>>> It's just what I want to discuss.
>>> In fact, I don't have any logic to put SVG in the doc.
>>> I heard many signage players support SVG documents.
>>> So I put it in the doc. That's it for now.
>>> But I don't know SVG is actually and commonly used in the signage 
>>> industry around the globe.
>>> SVG is not common at least in Japan.
>>> Personally, I think SVG may be put away from the Core Profile.
>>> If needed, it can be put in an another profile, such as "Content 
>>> Type Profile".
>>>
>>> Your comment is very helpful.
>>> I'll wait for other member's opininons for a while.
>>> If no one disagrees with putting it away, I'll delete it from the 
>>> Core Profile.
>>>
>>> Cheers,
>>> Futomi
>>>
>>> On Thu, 23 May 2013 12:35:37 +0800
>>> "John C. Wang" <John.Wang@IAdea.com> wrote:
>>>
>>>> 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/co
>>>>> mmit/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/#v
>>>>>>> iewport_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_f
>>>>>>> or_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 Friday, 24 May 2013 19:37:05 UTC