RE: [emergency] Groups - EDXL/CAP Routing Concepts and Issues(OASIS Input of Routing Concepts IEPD Version 0.4.pdf)uploaded

["Lee Tincher" <ltincher@evotecinc.com>]

I am in complete agreement with Art's statement below - this should be a DE
function....

Thanks,

Lee

'We the unwilling, led by the unknowing have been doing the difficult with
little for so long that we are now ready to tackle the impossible with
nothing.' -- Local Fire communications reserve volunteer motto


-----Original Message-----
From: Art Botterell [mailto:ABott@so.cccounty.us] 
Sent: Friday, November 30, 2007 4:59 PM
To: rlake@galdosinc.com; emergency@lists.oasis-open.org; dellis@sandia.gov
Subject: Re: [emergency] Groups - EDXL/CAP Routing Concepts and Issues(OASIS
Input of Routing Concepts IEPD Version 0.4.pdf)uploaded

Even before that there's the question of whether routing information, as
distinct from hazard-descriptive information, belongs in CAP at all.  Maybe,
as was suggested earlier, routing should be handled in the DE instead.  

I think that might make sense, since any routing directive that's different
from the hazard area is an artifact of some policy or infrastructure
constraint that may well come from some entity other than the originator.
If we put such third-party instructions  in the CAP structure itself, that
could force a lot of avoidable re-signings of the core message.  (Plus it
would create an unnecessary duplication of function with the DE.)

- Art
  
-----Original Message----- 
From: "Ron Lake" <rlake@galdosinc.com> 
To:  <emergency@lists.oasis-open.org> 
To:  <dellis@sandia.gov> 
 
Sent: 11/30/2007 12:47:47 PM 
Subject: RE: [emergency] Groups - EDXL/CAP Routing Concepts and Issues
(OASIS Input of Routing   Concepts IEPD Version 0.4.pdf) uploaded 
 
Hi, 
 
This speaks to the need to have a property concept (as in GML) that
expresses the role of the geometry (area) in relation to the feature (event)
of interest. This would deal directly with the question raised. 
 
In GML one would make use of a property name something as follows: 
 
	<abc:Alert gml:id="p1454"> 
		<abc:impactArea> .. polygon .. </abc:impactArea> 
		<abc:alertArea> ... polygon ... </abc:alertArea> 
	</abc:Alert> 
 
Cheers 
 
R 
 
-----Original Message----- 
From: dellis@sandia.gov [mailto:dellis@sandia.gov]  
Sent: November 30, 2007 12:21 PM 
To: emergency@lists.oasis-open.org 
Subject: [emergency] Groups - EDXL/CAP Routing Concepts and Issues (OASIS
Input of Routing Concepts IEPD Version 0.4.pdf) uploaded 
 
The document named EDXL/CAP Routing Concepts and Issues (OASIS Input of 
Routing Concepts IEPD Version 0.4.pdf) has been submitted by David Ellis to 
the OASIS Emergency Management TC document repository. 
 
Document Description: 
The current CAP standard requires the use of the "area" and sub elements to 
be the union of all Area blocks.  This raises a problem for systems which 
actual do GeoSpatial and GeoPolicitcal (Jurisdictional) routing of CAP 
messages.  The lack of ability to label one area block as the "true" area 
for alerting target population AOW (headline, instruction etc.) and another 
area block as the time evolving plume from a "Hazmat" event (AOH) makes 
meaningful use of CAP standard very difficult.  
 
View Document Details: 
http://www.oasis-open.org/apps/org/workgroup/emergency/document.php?document
_id=26274 
 
Download Document:   
http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/26274/OA
SIS%20Input%20of%20Routing%20Concepts%20IEPD%20Version%200.4.pdf 
 
 
PLEASE NOTE:  If the above links do not work for you, your email application

may be breaking the link into two pieces.  You may be able to copy and paste

the entire link address into the address field of your web browser. 
 
-OASIS Open Administration 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php