OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [emergency] Groups - CAP_scenarios_5-19-03.doc uploaded


At 6:59 AM -0700 5/20/03, Rex Brooks wrote:
>1. The use cases for CAP don't specify transport protocol, nor the 
>specific formulations or API required by http v. https v. wap or 
>markup language/specification, e.g. voiceXML, etc,

You're right, and that's all deliberate.  If you refer back to the 
requirements document you'll see that transport-layer independence is 
a mandatory.  CAP might be used in a number of contexts... various 
IP-based frameworks including web services, of course, but also over 
broadcast links, relatively low-bandwidth links and (alas) 
proprietary data-transport mechanisms.

>2. The use cases for CAP don't specify an order of priority for 
>recipients of alerts (probably should be part of cap:msg_scope), nor 
>an acknowledgement requirement which would then stop a repeated 
>transmission to specific recipients, although there is an"Ack" 
>cap:msg_type.

Neither a transmission-priority scheme nor a message-management 
scheme is inherent to CAP... both are left to the implementation, in 
large part because of our platform-independence goal as described 
above.  But we're attempting to include all the information required 
to implement such services.

In a way this underscores a distinction that keeps coming forward in 
my mind... between developing an application and specifying an event 
(which is what an alerting message is)... or viewed another way, 
between a node-centric approach and a network-centric one.  In the 
case of CAP... and probably of a number of the messages we'll be 
dealing with in this TC... the documents we're designing will have to 
fit between diverse (and sometimes unknown) nodes, applications and 
processes.

It would be easier, of course, and plenty comforting, if we could 
specify the processes at both ends, but that's not always possible.

>A procedural primer would probably be a good idea.

Providing it's a good process, of course!  In the absence of a 
standardized procedure, the Notifications SC has agreed on a general 
work sequence... requirements->use case->object model->data 
dictionary->schema (and possibly implementation notes)... and we're 
walking through the process with CAP (which is actually a relatively 
mature design) as a bellwether project to shake out the bugs.

Thanks!

- Art


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]