- From: Franck Dupin <franck.dupin@innes.fr>
- Date: Wed, 29 May 2013 08:26:42 +0200
- To: "'Futomi Hatano'" <futomi.hatano@newphoria.co.jp>, "'John C. Wang'" <John.Wang@IAdea.com>
- Cc: <public-websignage@w3.org>
- Message-ID: <004401ce5c35$7eca43d0$7c5ecb70$@innes.fr>
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 ,...). Reference would 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> 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" < <mailto:John.Wang@IAdea.com> 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> 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 > > > > > > > > > > < <mailto:20130528020224.018E.17D6BAFB@newphoria.co.jp> 20130528020224.018E.17D6BAFB@newphoria.co.jp> の、 > > "Re[2]: To discuss the title, I opend my draft" において、 > > "Futomi Hatano < <mailto:futomi.hatano@newphoria.co.jp> 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> 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 < <mailto:sa-takagi@kddi.com> 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> 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 > >>>> < <mailto:sa-takagi@kddi.com> 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> 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 > >>>>>> < <mailto:sa-takagi@kddi.com> 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/> 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 > >>>>>>>> < <mailto:sa-takagi@kddi.com> 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 > >>>>>>>> -- > >>>>>>>> <mailto:futomi.hatano@newphoria.co.jp> futomi.hatano@newphoria.co.jp <http://www.newphoria.co.jp/> http://www.newphoria.co.jp/ > >>>>>>>> > >>>>>>>> > >>>>>>>> > >> -- > >> 株式会社ニューフォリア > >> 取締役 最高技術責任者 > >> 羽田野 太巳 （はたの ふとみ） > >> <mailto:futomi.hatano@newphoria.co.jp> futomi.hatano@newphoria.co.jp > >> <http://www.newphoria.co.jp/> http://www.newphoria.co.jp/ > >> > >> > >> > -- 株式会社ニューフォリア 取締役 最高技術責任者 羽田野 太巳 （はたの ふとみ） <mailto:futomi.hatano@newphoria.co.jp> futomi.hatano@newphoria.co.jp <http://www.newphoria.co.jp/> http://www.newphoria.co.jp/
Received on Wednesday, 29 May 2013 06:27:37 UTC