Re: To discuss the title, I opend my draft

Thanks for the explanation. I think the way we are okay for this to work 
is that it is OKAY to use JS API between the content and the 
driver/hardware, but not use the HTML <object> or <embed> tags, right?

So long as the proprietary API exposes a JavaScript interface, then it 
is considered "web-only technology", correct? I am okay with that but 
doubt if that is more of a purist's point view than really contributing 
to interoperability.

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

On 5/29/2013 2:26 PM, Franck Dupin wrote:
>
> Hi all,
>
> >... my intention is excluding proprietary technologies, such as Flash, Silverlight, 
> Visual Basic, Action Script, etc.
>
> >I don't exclude the content consists of interactivity components using hardware 
> devices if they are controled using JavaScript.
>
> I agree with your point of view. But I think it isn't necessary to go 
> very far into the details of device support  (GPIO, detection by 
> camera, NFC ...) because it falls more in the spectrum of Web App 
> Runtime (Firefox OS, Tizen, Windows 8, ...) or Browser with WebIDL 
> dedicated (http://dev.webinos.org/specifications/draft/nfc.html, 
> https://developer.tizen.org/help/index.jsp?topic=%2Forg.tizen.web.device.apireference%2Ftizen%2Fnfc.html 
> ,...). Referencewould be enough, no ?
>
> About proprietary technologies/runtimes, I think it isn't really 
> topical because the tendency of ISVs ( digital signage  oriented) is 
> to design a web based middleware or use it. The scope of the 
> specification seems very good….
>
> 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 : Futomi Hatano [mailto:futomi.hatano@newphoria.co.jp]
> Envoyé : mercredi 29 mai 2013 07:51
> À : John C. Wang
> Cc : public-websignage@w3.org
> Objet : Re[2]: To discuss the title, I opend my draft
>
> Hi John,
>
> The first sentence is originally  in the doc.
>
> http://futomi.github.io/Web-based_Signage_Player_Core_Profile/#web-based_signage
>
> I wrote it. I think he just copied it.
>
> Though I don't know Satoru's intention,
>
> my intention is excluding proprietary technologies, such as Flash, 
> Silverlight, Visual Basic, Action Script, etc.
>
> I don't exclude the content consists of interactivity components using 
> hardware devices if they are controled using JavaScript.
>
> Cheers,
>
> Futomi
>
> On Wed, 29 May 2013 12:52:11 +0800
>
> "John C. Wang" <John.Wang@IAdea.com <mailto:John.Wang@IAdea.com>> wrote:
>
> > Dear Satoru-san:
>
> >
>
> > I don't quite understand the goal of the first sentence in your
>
> > "concept" section:
>
> >
>
> > "Web-based signage is digital signage whose contents are created by 
> only web-technologies."
>
> >
>
> >
>
> > I assume you don't mean it literally as "only web-technologies". For
>
> > example, if the content consists of interactivity components using
>
> > GPIO devices, motion sensors, or NFC readers, I am quite sure you are
>
> > not trying to exclude them from the definition. So please kindly
>
> > explain what you try to exclude from our work so I can understand the
>
> > purpose better.
>
> >
>
> > Thank you.
>
> >
>
> > John C. Wang
>
> > IAdea: Digital Signage Media Appliances http://www.IAdea.com
>
> > Skype: jcwang_tw
>
> >
>
> > On 5/28/2013 5:03 PM, Satoru Takagi wrote:
>
> > > Hi Futomi san,
>
> > >
>
> > >> I'd like to know your ideal modifications to the doc.
>
> > > Title and sub-title;
>
> > > "Architecture and Requirements for Web-based Signage Player"
>
> > > -- Core Feature
>
> > > #I prefer 'feature' than 'profile'.
>
> > >
>
> > > Add a Concept chapter before Terminology;
>
> > > Concept:
>
> > > The "Features for Web-based Signage Player" defines precise
>
> > > requirements for web-based signage players.
>
> > >
>
> > > Web-based signage is digital signage whose contents are created by
>
> > > only web-technologies. Besides, it has a capability of connecting to
>
> > > a network. It is not a matter whether the network is the Internet 
> or not. The web-based signage includes the terminal in an intranet.
>
> > >
>
> > > Web-based Signage Player in this document is the composition of the
>
> > > device to play contents for Web based signage. However, this
>
> > > document is not aimed for limitation of underlying hardware and the
>
> > > operating system. Therefore, in this document, Web-based Signage 
> Player is application software to play contents.
>
> > >
>
> > > Web-based signage Player is a set of an application and a runtime.
>
> > >
>
> > > The application is comprised of the software such as frameworks or 
> the libraries for signage.
>
> > > Architecture and functions of the application will be prescribed 
> as features for web-based signage.
>
> > > The application is a set of JavaScript programs and style sheets and
>
> > > HTML. An application is run on a runtime, fetches contents form a 
> content server, then plays the contents appropriately.
>
> > >
>
> > > The runtime is common browsers typically. Or it may be software with
>
> > > the functions that is equal to common browsers associated with the
>
> > > operating system. On the other hand, it is not a dedicated subset or
>
> > > subset-based derivation of HTML5 in wide sense. That is, the runtime
>
> > > offers functions called HTML5 in the wide sense. The 
> specifications of HTML5 in wide sense will be provided particularly by 
> W3C.
>
> > >
>
> > > Therefore, web-based signage player has a function of HTML5 in wide
>
> > > sense that runtime has. And this  document does not restrict the
>
> > > function of the player for contents using functions and expressions
>
> > > based on HTML5 in wide sense even if it is out of the range of
>
> > > feature shown in this document,
>
> > >
>
> > > The features for web-based signage player consist of a number of
>
> > > features. Basically, web-based signage is based on the core feature
>
> > > (this document). As necessary, web-based signage systems adopt the 
> other features additionally.
>
> > >
>
> > > Terminology chapter;
>
> > > Items of Web-based signage, runtime and player are substituted 
> with a concept chapter.
>
> > >
>
> > >
>
> > > Regards,
>
> > >
>
> > > Satoru
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > <20130528020224.018E.17D6BAFB@newphoria.co.jp 
> <mailto:20130528020224.018E.17D6BAFB@newphoria.co.jp>> の、
>
> > >    "Re[2]: To discuss the title, I opend my draft" において、
>
> > >    "Futomi Hatano <futomi.hatano@newphoria.co.jp 
> <mailto:futomi.hatano@newphoria.co.jp>>"さんは書き ました：
>
> > >
>
> > >> Hi Satoru-san,
>
> > >>
>
> > >>> I understood your intention. On the other hand, I cannot have
>
> > >>> conviction that the consensus of
>
> > > this
>
> > >>> BG member accords with it.
>
> > >> Yes, I think so too.
>
> > >> However, I'd like to build consensus with as many members as
>
> > >> possible, and find common ground.
>
> > >>
>
> > >>> Do we only define the requirements of web based signage as
>
> > >>> libraries or frameworks for common browsers (HTML5 in wide sense)?
>
> > >>>
>
> > >>> Or do we put the dedicated native signage player based on these
>
> > >>> requirements not to be based on common browsers in our scope? 
> There are many native code "player" in the world.
>
> > >> The former.
>
> > >> If a "native player" means a player based on a proprietary platform
>
> > >> or a non-HTML UA, it is not in our scope.
>
> > >>
>
> > >> In the doc, the term "runtime" is used for common browsers.
>
> > >> http://futomi.github.io/Web-based_Signage_Player_Core_Profile/#runt
>
> > >> ime
>
> > >>
>
> > >>> I think that this is one of a important point. And I think that we
>
> > >>> should specify it in this document by the situation of consensus.
>
> > >> I'd like to know your ideal modifications to the doc.
>
> > >> What phrases should we add or delete or change?
>
> > >> What are your ideal main title and sub title?
>
> > >> I'd like to hear your ideal concretely.
>
> > >>
>
> > >> Cheers,
>
> > >> Futomi
>
> > >>
>
> > >>
>
> > >> On Mon, 27 May 2013 14:00:22 +0900
>
> > >> Satoru Takagi <sa-takagi@kddi.com <mailto:sa-takagi@kddi.com>> wrote:
>
> > >>
>
> > >>> Hi Futomi san,
>
> > >>>
>
> > >>> I understood your intention. On the other hand, I cannot have
>
> > >>> conviction that the consensus of
>
> > > this
>
> > >>> BG member accords with it.
>
> > >>>
>
> > >>> Do we only define the requirements of web based signage as
>
> > >>> libraries or frameworks for common browsers (HTML5 in wide sense)?
>
> > >>>
>
> > >>> Or do we put the dedicated native signage player based on these
>
> > >>> requirements not to be based on common browsers in our scope? 
> There are many native code "player" in the world.
>
> > >>>
>
> > >>> It will be considered that it is a profile of the subsets of HTML5
>
> > >>> in wide sense if expectation
>
> > > to
>
> > >>> the latter is included.
>
> > >>>
>
> > >>> I think that this is one of a important point. And I think that we
>
> > >>> should specify it in this document by the situation of consensus.
>
> > >>>
>
> > >>> Regards,
>
> > >>>
>
> > >>> Satoru
>
> > >>>
>
> > >>>
>
> > >>>> Hi Satoru-san,
>
> > >>>>
>
> > >>>> Thanks for your opinion.
>
> > >>>>
>
> > >>>> You possibly misunderstand the purpose of the set of docs.
>
> > >>>> The docs are *not* subsets of some specs such as HTML5 in wide
>
> > >>>> senses,
>
> > >>>> *nor* requirements for UAs.
>
> > >>>>
>
> > >>>> The docs are mainly requirements for *applications* (i.e. JS 
> library).
>
> > >>>> The docs define use cases for web-based signage, then they define
>
> > >>>> requirements for *applications*.
>
> > >>>> As written in the Core Profile, through these activities, the our
>
> > >>>> BG aims to find required APIs or functions for web-based signage,
>
> > >>>> and propose the relevant working groups as necessary.
>
> > >>>> http://futomi.github.io/Web-based_Signage_Player_Core_Profile/#in
>
> > >>>> troduction For the aim, we must know whether the use cases can be
>
> > >>>> achieved existing web technologies or not.
>
> > >>>> Therefore, the docs describe how to achieve each use cases
>
> > >>>> regarding use cases which can be achieved using existing web 
> technologies.
>
> > >>>> This is not intended to limit implementations of UAs.
>
> > >>>>
>
> > >>>> Besides, in order to prevent fragmentation which you worry about,
>
> > >>>> the docs are based on "common browsers", not signage-dedicated UAs.
>
> > >>>>
>
> > >>>> Have I made yourself clear?
>
> > >>>>
>
> > >>>> Cheers,
>
> > >>>> Futomi
>
> > >>>>
>
> > >>>>
>
> > >>>> On Mon, 27 May 2013 10:41:10 +0900 Satoru Takagi
>
> > >>>> <sa-takagi@kddi.com <mailto:sa-takagi@kddi.com>> wrote:
>
> > >>>>
>
> > >>>>> Hi Futomi san,
>
> > >>>>>
>
> > >>>>> >From this discussion, now I supposed that the thing which you
>
> > >>>>> >were aimed for in this
>
> > > document
>
> > >>> was
>
> > >>>>> feature which I interpretd. And I also supposed that it was a 
> subset of HTML5 in wide senses.
>
> > >>>>>
>
> > >>>>> On the other hand, the fullset here (as I interpretd) is a set
>
> > >>>>> of greatest common features
>
> > > that
>
> > >>> is
>
> > >>>>> supported with all the well known web browsers. Of course it has
>
> > >>>>> many ambiguity. Such as,
>
> > > what
>
> > >>> is
>
> > >>>>> common browser? Whether it includes SmartPhones or only PCs?
>
> > >>>>> etc.  But it will become the
>
> > > common
>
> > >>>
>
> > >>>>> recognition roughly. And it will be the almost same as HTML5 in
>
> > >>>>> wide sense. At least it will
>
> > >  be
>
> > >>> a
>
> > >>>>> big feature set than it is mentioned in this document.
>
> > >>>>>
>
> > >>>>> On the other hand, in this document and recent discussion about
>
> > >>>>> it, providing a profile of
>
> > > the
>
> > >>>>> subset against aforementioned fullset is a main topic.
>
> > >>>>>
>
> > >>>>> I think that it may become the standard that we can consider to
>
> > >>>>> be a player in conformity
>
> > > with
>
> > >>>>> profile for web based signage although this is subset. In this
>
> > >>>>> point, I concern about
>
> > >>> fragmentation
>
> > >>>>> the Web. This is because, in spite of contents to work on well
>
> > >>>>> known Web browsers, there are
>
> > >
>
> > >>> cases
>
> > >>>>> that this contents does not work in the players in accordance 
> with only this subset.
>
> > >>>>>
>
> > >>>>> If this document does not intend to promote the player of such a
>
> > >>>>> HTML5 subset player, we
>
> > > should
>
> > >>> make
>
> > >>>>>  the object of this document to contents.
>
> > >>>>>
>
> > >>>>> In the item of "may" in standards for players, a player does not
>
> > >>>>> need to implement the specifications. On the other hand, it is
>
> > >>>>> almost necessary for a player to implement the specifications in
>
> > >>>>> the item of "may" in a standard for contents. In this way,
>
> > >>>>> standards for
>
> > >>> contents
>
> > >>>>> is harder for players (UAs).
>
> > >>>>>
>
> > >>>>> # Of course I think that there is the choice to prescribe
>
> > >>>>> profile unlike HTML5 of the wide
>
> > > sense
>
> > >>>
>
> > >>>>> (includes subset of HTML5) after having considered an effect 
> in the busines.
>
> > >>>>>
>
> > >>>>>
>
> > >>>>> Regards,
>
> > >>>>>
>
> > >>>>> Satoru
>
> > >>>>>
>
> > >>>>>> Hi Satoru,
>
> > >>>>>>
>
> > >>>>>> I know your anxiety.
>
> > >>>>>> But I think you are a little bit too worried regarding the 
> sub title.
>
> > >>>>>>
>
> > >>>>>> Let me explain the meanings of the main title and the sub 
> title at first.
>
> > >>>>>>
>
> > >>>>>> * The main title
>
> > >>>>>> This is a collective term representing the set of docs we are 
> planning to make.
>
> > >>>>>>
>
> > >>>>>> * The sub title
>
> > >>>>>> This is a title representing each doc, such as "Core", 
> "Media", etc.
>
> > >>>>>>
>
> > >>>>>> As you know, the set of the docs is not a subset of a specific
>
> > >>>>>> specification something, such as SVG Tiny, Compact HTML.
>
> > >>>>>> It's just requirements for web-based signage.
>
> > >>>>>> It is not intended to introduce fragmentation to the WEB.
>
> > >>>>>> I agree that the term "Profile" is not appropriate for the main
>
> > >>>>>> title, because the set of docs is not a subset of something.
>
> > >>>>>> On the other hand, the each doc is a subset of the 
> requirements (the set of the docs).
>
> > >>>>>>
>
> > >>>>>> However, the term "profile" does not mean "subset" literally.
>
> > >>>>>> It means just a description of characteristics of something.
>
> > >>>>>> http://oald8.oxfordlearnersdictionaries.com/dictionary/profile
>
> > >>>>>> Generally, it doesn't imply "fragmentation" nor "subset".
>
> > >>>>>>
>
> > >>>>>> I think the term "profile" is not inappropriate for the sub
>
> > >>>>>> title, and no one misunderstands the meanings reading 
> "profile" in the sub title.
>
> > >>>>>>
>
> > >>>>>> How about renaming the sub title *if by any chance* some 
> people misunderstand?
>
> > >>>>>>
>
> > >>>>>> Cheers,
>
> > >>>>>> Futomi
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>> On Fri, 24 May 2013 19:06:14 +0900 Satoru Takagi
>
> > >>>>>> <sa-takagi@kddi.com <mailto:sa-takagi@kddi.com>> wrote:
>
> > >>>>>>
>
> > >>>>>>> Hi Futomi san,
>
> > >>>>>>>
>
> > >>>>>>> I am circumspect about defining "Profiles" regardless of "Core".
>
> > >>>>>>> It may affect what we want to promote web based signage
>
> > >>>>>>> relying on. The core of the
>
> > > profile
>
> > >>> will
>
> > >>>>>
>
> > >>>>>>> depend on HTML5 in wide sense if we want to rely on HTML5 in
>
> > >>>>>>> wide sense. But HTML5 in
>
> > > wide
>
> > >>>>> sense
>
> > >>>>>>> does not seem to be prescribed closely. However, the outline 
> is seen in various places.
>
> > >  For
>
> > >>>
>
> > >>>>> example,
>
> > >>>>>>>  it is suggested on the page of HTML5 Logo of the W3C. *1 
>
> > >>>>>>> Therefore, it will become the
>
> > >
>
> > >>>>> important
>
> > >>>>>>> requirements that profile of web based signage is based on 
> such things.
>
> > >>>>>>>
>
> > >>>>>>> On the other hand, we should prescribe original Profile if we
>
> > >>>>>>> do not want to rely on
>
> > > HTML5
>
> > >>> in
>
> > >>>>> wide
>
> > >>>>>>> sense. In addition, I do not like that TV and Mobile and
>
> > >>>>>>> Signage have individual Profile
>
> > >
>
> > >>> very
>
> > >>>>> much.
>
> > >>>>>>> Because they may promote fragmentation of the WWW.
>
> > >>>>>>>
>
> > >>>>>>> I wish one general-purpose not specific use cases oriented
>
> > >>>>>>> Profile called HTML5 in wide
>
> > >>> sense is
>
> > >>>>>
>
> > >>>>>>> established first.
>
> > >>>>>>>
>
> > >>>>>>> *1: http://www.w3.org/html/logo/ In this page's class section,
>
> > >>>>>>> the followings are enumerated.
>
> > >>>>>>> HTML5, RDFa, microdata, microformats, App Cache, Local
>
> > >>>>>>> Storage, Indexed DB, File API,
>
> > >>>>> Geolocation
>
> > >>>>>>> API, audio/video input, contacts & events, tilt orientation,
>
> > >>>>>>> Web Sockets, Server-Sent
>
> > > Events,
>
> > >>>
>
> > >>>>> Audio,
>
> > >>>>>>> video, SVG, Canvas, WebGL, CSS3 3D, Web Workers,
>
> > >>>>>>> XMLHttpRequest 2, CSS3, WOFF
>
> > >>>>>>>
>
> > >>>>>>> Regards,
>
> > >>>>>>>
>
> > >>>>>>> Satoru
>
> > >>>>>>>
>
> > >>>>>>>> Hi Satoru,
>
> > >>>>>>>>
>
> > >>>>>>>> Thanks for your comment.
>
> > >>>>>>>> Responses inline below.
>
> > >>>>>>>>
>
> > >>>>>>>> On Tue, 21 May 2013 12:07:51 +0900 Satoru Takagi
>
> > >>>>>>>> <sa-takagi@kddi.com <mailto:sa-takagi@kddi.com>> wrote:
>
> > >>>>>>>>
>
> > >>>>>>>>> Hi Futomi san,
>
> > >>>>>>>>>
>
> > >>>>>>>>> Thank you for publication of your hard work.
>
> > >>>>>>>>>
>
> > >>>>>>>>> I read the document. And I understood that the positioning
>
> > >>>>>>>>> of this document is  the
>
> > >>>>> followings
>
> > >>>>>>> for
>
> > >>>>>>>>> contents for signage player.
>
> > >>>>>>>>> * Definition of a term and the concept (Or it is the
>
> > >>>>>>>>> architecture and model.)
>
> > >>>>>>>>> * Detailed requirements
>
> > >>>>>>>> Definitely yes.
>
> > >>>>>>>> As your understanding, the document defines just detailed 
> requirements.
>
> > >>>>>>>>
>
> > >>>>>>>>> I think that this is an important document for this BG.
>
> > >>>>>>>>>
>
> > >>>>>>>>> Now, I consider "Profile" at W3C to be the subsets or
>
> > >>>>>>>>> collections of individual
>
> > > features
>
> > >>>  and
>
> > >>>>>
>
> > >>>>>>>>> functions in existing standards. Therefore I thought this
>
> > >>>>>>>>> document to be different
>
> > > >from
>
> > >>>>> profile.
>
> > >>>>>>>> Exactly.
>
> > >>>>>>>> It seems to be better to change "Profile" to the other term.
>
> > >>>>>>>>
>
> > >>>>>>>>> How about the following titles?
>
> > >>>>>>>>> "Architecture and Requirements for Web-based Signage Player"
>
> > >>>>>>>> Sounds nice.
>
> > >>>>>>>> Thanks for your idea.
>
> > >>>>>>>>
>
> > >>>>>>>> BTW, how do you think "profile" in "Core profile"?
>
> > >>>>>>>> The term "profile" in "Core profile" means a subset of the 
> documents we are addressing.
>
> > >>>>>>>> Is it confusing?
>
> > >>>>>>>>
>
> > >>>>>>>> Cheers,
>
> > >>>>>>>> Futomi
>
> > >>>>>>>>
>
> > >>>>>>>> --
>
> > >>>>>>>> Newphoria Corporation
>
> > >>>>>>>> Chief Technology Officer
>
> > >>>>>>>> Futomi Hatano
>
> > >>>>>>>> --
>
> > >>>>>>>> futomi.hatano@newphoria.co.jp 
> <mailto:futomi.hatano@newphoria.co.jp> http://www.newphoria.co.jp/
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >> --
>
> > >> 株式会社 ニューフォリア
>
> > >> 取締役最高技術責任者
>
> > >> 羽田野太巳（はたのふとみ）
>
> > >> futomi.hatano@newphoria.co.jp <mailto:futomi.hatano@newphoria.co.jp>
>
> > >> http://www.newphoria.co.jp/
>
> > >>
>
> > >>
>
> > >>
>
> >
>
> -- 
>
> 株式会社ニューフォリア
>
> 取締役最高技術責 任者
>
> 羽田野太巳（はたのふとみ）
>
> futomi.hatano@newphoria.co.jp <mailto:futomi.hatano@newphoria.co.jp>
>
> http://www.newphoria.co.jp/
>