- From: Futomi Hatano <futomi.hatano@newphoria.co.jp>
- Date: Wed, 29 May 2013 14:51:27 +0900
- To: "John C. Wang" <John.Wang@IAdea.com>
- Cc: public-websignage@w3.org
Hi John, The first sentence is originally written 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> 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> の、 > > "Re[2]: To discuss the title, I opend my draft" において、 > > "Futomi Hatano <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/#runtime > >> > >>> 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> 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/#introduction > >>>> 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> 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> 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> 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 > >>>>>>>> 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 Wednesday, 29 May 2013 05:51:15 UTC