[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]