- From: Satoru Takagi <sa-takagi@kddi.com>
- Date: Wed, 29 May 2013 15:25:20 +0900
- To: public-websignage@w3.org
Hi Mr. John, I simply copied it as Futomi-san pointed it out. And my intention align with Futomi-san, too. As supplement, scope of the future HTML in wide sense will have the standard for access of a variety of devices. DAP-WG and SysApps-WG work on them. Therefore, we should pay interest to those activities. This is because the device access mechanism for signage should match such a general- purpose framework. Regards, Satoru > 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 06:27:24 UTC