MHonArc v2.5.0b2 -->
emergency-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency-msg] EM TC Notifications, Methods and Messaging 09-16-03 Meeting Minutes
At 3:28 PM -0400 9/20/03, R. Allen Wyke wrote:
>So they only plan on supporting CAP 1.0 then? They do not plan on
>building their apps so they can support future versions of the standard?
Don't know. As I understand it, these and various other folks are
planning to deploy hardware in mass quantities. Those devices may or
may not be reprogrammable once deployed.
Anyway, if a standard doesn't provide some reasonable degree of
stability, its going to be of fairly limited value.
- Art
PS - That's why we put the version number in the default namespace
id... so folks can detect different versions and maintain backward
compatibility if/when there's a next version.
>On Sat, 2003-09-20 at 14:30, Art Botterell wrote:
>> At 12:35 PM -0400 9/20/03, R. Allen Wyke wrote:
>> >If they can't resolve a URI, how do they plan on validating the message
>> >against a schema?
>>
>> Just speculating... but I imagine they could validate against a local
>> cached schema... or even use a non-validating parser and handle any
>> resulting data errors downstream in the application. We aren't
>> always talking about what we normally think of as "computers" here...
>> many CAP consumers will be embedded "thin" devices.
>>
>> Anyway, any consumer on a one-way link will have a problem with
>> retrieving updates. My understanding is that that's precisely why
>> the warning-systems industry is interested in a standard... because
>> once they start deploying firmware in commercial quantities it won't
>> be feasible for them to chase a moving-target schema.
>>
>> Certainly we're addressing a broader user community here than in some
>> other OASIS projects. Still, supporting use of CAP over one-way
>> channels has been one of our explicit requirements since the
>> beginning. What I'm hearing here is feedback from users who care
>> about that particular use case and aren't persuaded that we've met
>> that requirement.
>>
>> - Art
> >
>> To unsubscribe from this mailing list (and be removed from the
>>roster of the OASIS TC), go to
>>http://www.oasis-open.org/apps/org/workgroup/emergency-msg/members/leave_workgroup.php.
>--
>R. Allen Wyke
>Chair, Emergency Management TC
>emtc@nc.rr.com
>http://www.oasis-open.org/committees/emergency
>
>
>To unsubscribe from this mailing list (and be removed from the
>roster of the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/emergency-msg/members/leave_workgroup.php.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]