- From: Satoru Takagi <sa-takagi@kddi.com>
- Date: Wed, 29 May 2013 16:48:11 +0900
- To: public-websignage@w3.org
Hi Futomi san, > If you don't stick with the term "feature", > let me propose another term. > I'd like to make the sub title imply that each doc is a component > of the "Architecture and Requirements for Web-based Signage Player". > How about "module"? Core Module, Basic Media Module, etc. I don't stick with the term "feature". Module may be good, too. If there is somebody who knows the term in the W3C historically and is English native speakers, please advise it. > I think it may be better to merge the terminology chapter and > the concept chapter into one chapter as: > "2. Concept of "Architecture and Requirements" and terminology > Anyway, I'll try to put your draft into the doc. agreed too. Regards, Satoru <20130529115517.D18D.17D6BAFB@newphoria.co.jp> の、 "Re[2]: To discuss the title, I opend my draft" において、 "Futomi Hatano <futomi.hatano@newphoria.co.jp>"さんは書きました： > Hi Satoru-san, > > Thank you for your contribution. > > > Title and sub-title; > > "Architecture and Requirements for Web-based Signage Player" > > agreed. > > > -- Core Feature > > #I prefer 'feature' than 'profile'. > > OK. I know you don't agree to use the term "profile" for even the sub title. > I don't stick with it. > If you don't stick with the term "feature", > let me propose another term. > I'd like to make the sub title imply that each doc is a component > of the "Architecture and Requirements for Web-based Signage Player". > How about "module"? Core Module, Basic Media Module, etc. > > > > Add a Concept chapter before Terminology; > > Concept: > > I completely agree your draft of the concept chapter. > I'll wait for other opinions for a few days, > then I'll add the chapter before the terminology chapter > if there are no objections from the other members. > > > Terminology chapter; > > Items of Web-based signage, runtime and player are substituted with a concept chapter. > > I think it may be better to merge the terminology chapter and > the concept chapter into one chapter as: > "2. Concept of "Architecture and Requirements" and terminology > Anyway, I'll try to put your draft into the doc. > > Cheers, > Futomi > > > > On Tue, 28 May 2013 18:03:47 +0900 > Satoru Takagi <sa-takagi@kddi.com> 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/ > > > > > > > > > > > > > -- > > 高木 悟（Satoru Takagi) > > ＫＤＤＩ株式会社 技術開発本部 > > 技術戦略部 サービスフロンティアグループ > > Email:sa-takagi@kddi.com > > > > この電子メール及び添付書類は名宛人のための秘密情報を含んで > > います。名宛人以外の方が受信された場合は、お手数をお掛けい > > たしますが、破棄をお願いいたします。 > > -- > 株式会社ニューフォリア > 取締役 最高技術責任者 > 羽田野 太巳 （はたの ふとみ） > futomi.hatano@newphoria.co.jp > http://www.newphoria.co.jp/ > > > -- 高木 悟（Satoru Takagi) ＫＤＤＩ株式会社 技術開発本部 技術戦略部 サービスフロンティアグループ Email:sa-takagi@kddi.com この電子メール及び添付書類は名宛人のための秘密情報を含んで います。名宛人以外の方が受信された場合は、お手数をお掛けい たしますが、破棄をお願いいたします。
Received on Wednesday, 29 May 2013 07:48:59 UTC