Re[2]: Some comments

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/
> >>>>
> 

-- 
株式会社ニューフォリア
取締役 最高技術責任者
羽田野 太巳 （はたの ふとみ）
futomi.hatano@newphoria.co.jp
http://www.newphoria.co.jp/

Received on Friday, 24 May 2013 03:59:31 UTC