Re[2]: Contribution for "Proposed initial draft of "Architecture and Requirements for Web-based Signage Player - Emergency Information Profile"

Thanks for the excellent references, Franck.
And thanks for your thought, Wook.
My comments for Wook's comments inline:

On Mon, 6 Jan 2014 14:45:23 +0000
현욱 <whyun@etri.re.kr> wrote:

> BTW,
> Since the CAP already covers wide range of emergency information and widely used, we don¨t aiming at reinvent CAP-like something.
> So, we just want to focus on making presentation profile for emergency information using web technologies rather than redefining emergency state.
> As the name implies, this is a profile for player. :D

+1

> It¨s quite useful information, and should be studied in this BG.

Yes, I think so too.


> But, I¨m not sure whether this document should be tightly coupled with CAP or not. 
> I think the CAP is one of candidate(but most strong one :D), but not all of them. 
> I also think that signage player profile should be independent of underlying emergency system, like layering concept. 

+1
I don't think Data formats should not be defined in this doc too.
Though CAP is actually adopted widely, it isn't relevant to signage players directly.
Even if information distributers adopt CAP,
signage players necessarily don't communicate with their servers directly.
In many cases, signage operators aggregate such information,
then they redistribute the information to their players.
The data format which players receive isn't necessarily CAP.


> The ＾Classification of severity level for presentation￣ is not defining severity level of emergency but presentation/displaying level of information.
> In other words, this profile guides how to present emergency information using web technology.
> For example, (these are just examples, not refined)
> 
>  Level 1 : Lowest priority
>     - ticker box with font size, ratio
>     - Scroll text 
>     - repeat pattern
> 
>  Level N : Middle priority
>     - Pop-up in the middle of screen
>     - Blinking
>     - repeat pattern
> 
>  Level X : Highest priority
>     - Immediate display with full screen.
>     - Alarming with maximum sound.

It's the same as my recognition.


> BTW, I think it will be useful if we can provide mapping table between presentation level and priority of CAP. 
> This can be a separate document or can be attached at the end of document as an appendix.

+1
If possible, I prefer attaching it the end of the doc as an appendix.


> > 3/  Reception of emergency information
> > ＾We are considering WebSocket or HTTP PUSH for this.￣ Why not but have a look at :
> >  
> > XEP-0127: Common Alerting Protocol (CAP) Over XMPP :  <http://xmpp.org/extensions/xep-0127.html>http://xmpp.org/extensions/xep-0127.html
> > PubSubHubbub:  ie http://alert-hub.appspot.com/ for  http://www.google.org/crisisresponse/
> 
> Yeah, right. If signage terminal is capable of XMPP, it can be used. 
> Even thought this profile is for web-based signage, It will be good if we can provide several candidates.

Currently, the popular browsers support only HTTP/HTTPS (XHR/Server-Sent Events)
and WebSocket protocol.
If we use XMPP, we have to use it on HTTP/HTTPS or WebSocket.
That is, CAP over XMPP over WebSocket, for example.
In fact, WebRTC adopt this approach for signaling.

If we provide XMPP or PubSubHubbub in the doc,
we should mention the difference of the communication layers.

Cheers,
Futomi

p.s.
Franck, Wook,
You should not send HTML mails to this ML.
See the archive below:
http://lists.w3.org/Archives/Public/public-websignage/2014Jan/0006.html
It's not only unreadable, but also,
we cannot distinguish the original text from the reply.
If possible, I recommend plain-text mails.
Thank you.


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

Received on Tuesday, 7 January 2014 03:35:27 UTC