W3C home > Mailing lists > Public > public-websignage@w3.org > May 2013

Re: To discuss the title, I opend my draft

From: Satoru Takagi <sa-takagi@kddi.com>
Date: Wed, 29 May 2013 15:25:20 +0900
To: public-websignage@w3.org
Message-Id: <201305291525.HIE04643.BBTLUtBHJ@kddi.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:23:27 UTC