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

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 Monday, 27 May 2013 03:11:20 UTC