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/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 Friday, 24 May 2013 04:01:12 UTC