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 Messaging09-16-03 Meeting Minutes
Hmmmm, that certainly stimulates an interesting concept - addressing
people who *may* only want/can support just one version of the standard.
That they can't create a system that is upgradable.
I will need to noodle on that one. I admit its a first. Thanx for the
clarification - Allen
On Sat, 2003-09-20 at 15:49, Art Botterell wrote:
> 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.
>
>
> 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]