- From: John C. Wang <John.Wang@IAdea.com>
- Date: Wed, 29 May 2013 12:52:11 +0800
- To: public-websignage@w3.org
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/ >> >> >>
Received on Wednesday, 29 May 2013 04:52:51 UTC