Re[4]: To discuss the title, I opend my draft

+1

On Wed, 29 May 2013 08:26:42 +0200
"Franck Dupin" <franck.dupin@innes.fr> wrote:

> Hi all,
>  
> >... 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.
>  
> I agree with your point of view. But I think it isn't necessary to go very far into the details of device support ﾂ(GPIO, detection by camera, NFC ...) because it falls more in the spectrum of Web App Runtime (Firefox OS, Tizen, Windows 8, ...) or Browser with WebIDL dedicated (http://dev.webinos.org/specifications/draft/nfc.html, https://developer.tizen.org/help/index.jsp?topic=%2Forg.tizen.web.device.apireference%2Ftizen%2Fnfc.html ,...). Reference would be enough, no ?
>  
> About proprietary technologies/runtimes, I think it isn't really topical because the tendency of ISVs ( digital signage ﾂoriented) is to design a web based middleware or use it. The scope of the specification seems very good窶ｦ.
>  
>  
> Sincerly,
> Franck Dupin
>  
> INNES
> ZAC Atalante champeaux
> 5A rue Pierre Joseph Colin
> 35000 RENNES - FRANCE
> Tel: +33 (0)2 23 20 01 62 / Fax: +33 (0)2 23 20 22 59 / http://www.innes.pro
>  
>  
>  
>  
>  
>  
>  
> -----Message d'origine-----
> De : Futomi Hatano [mailto:futomi.hatano@newphoria.co.jp] 
> Envoyﾃｩ : mercredi 29 mai 2013 07:51
> ﾃ€ : John C. Wang
> Cc : public-websignage@w3.org
> Objet : Re[2]: To discuss the title, I opend my draft
>  
> Hi John,
>  
> The first sentence is originally ﾂin the doc.
> <http://futomi.github.io/Web-based_Signage_Player_Core_Profile/#web-based_signage>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" <<mailto:John.Wang@IAdea.com>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>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
> > >
> > >
> > >
> > >
> > > <<mailto:20130528020224.018E.17D6BAFB@newphoria.co.jp>20130528020224.018E.17D6BAFB@newphoria.co.jp> 縺ｮ縲・/span>
> > >ﾂﾂﾂ "Re[2]: To discuss the title, I opend my draft" 縺ｫ縺翫＞縺ｦ縲・/span>
> > >ﾂﾂﾂ "Futomi Hatano <<mailto:futomi.hatano@newphoria.co.jp>futomi.hatano@newphoria.co.jp>"縺輔ｓ縺ｯ譖ｸ縺阪∪縺励◆・・/span>
> > >
> > >> 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/#runt>http://futomi.github.io/Web-based_Signage_Player_Core_Profile/#runt
> > >> ime
> > >>
> > >>> 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 <<mailto:sa-takagi@kddi.com>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/#in>http://futomi.github.io/Web-based_Signage_Player_Core_Profile/#in
> > >>>> troduction 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 
> > >>>> <<mailto:sa-takagi@kddi.com>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>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 
> > >>>>>> <<mailto:sa-takagi@kddi.com>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/>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 
> > >>>>>>>> <<mailto:sa-takagi@kddi.com>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
> > >>>>>>>> --
> > >>>>>>>> <mailto:futomi.hatano@newphoria.co.jp>futomi.hatano@newphoria.co.jp <http://www.newphoria.co.jp/>http://www.newphoria.co.jp/
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >> -- 
> > >> 譬ｪ蠑丈ｼ夂､ｾ繝九Η繝ｼ繝輔か繝ｪ繧｢
> > >> 蜿也ｷ蠖ｹ 譛€鬮俶橿陦楢ｲｬ莉ｻ閠・/span>
> > >> 鄒ｽ逕ｰ驥・/span> 螟ｪ蟾ｳ ・医・縺溘・ 縺ｵ縺ｨ縺ｿ・・/span>
> > >> <mailto:futomi.hatano@newphoria.co.jp>futomi.hatano@newphoria.co.jp
> > >> <http://www.newphoria.co.jp/>http://www.newphoria.co.jp/
> > >>
> > >>
> > >>
> > 
>  
> -- 
> 譬ｪ蠑丈ｼ夂､ｾ繝九Η繝ｼ繝輔か繝ｪ繧｢
> 蜿也ｷ蠖ｹ 譛€鬮俶橿陦楢ｲｬ莉ｻ閠・/span>
> 鄒ｽ逕ｰ驥・/span> 螟ｪ蟾ｳ ・医・縺溘・ 縺ｵ縺ｨ縺ｿ・・/span>
> <mailto:futomi.hatano@newphoria.co.jp>futomi.hatano@newphoria.co.jp
> <http://www.newphoria.co.jp/>http://www.newphoria.co.jp/
>  
> 

--
Newphoria Corporation
Chief Technology Officer
Futomi Hatano
--
futomi.hatano@newphoria.co.jp
http://www.newphoria.co.jp/

Received on Wednesday, 29 May 2013 07:03:09 UTC