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] Re: [sia-pilot6] [emergency] EDXL-DE routing and valueListUrn

Rex -

Yup to which thought :-)

And Pericles, do you know Jeff Lansing? He works for SYS Technologies and
has attended many OGC meetings.



Also, > Yup.
> At 10:14 AM -0700 3/21/06, Carl Reed OGC Account wrote:
>>What he said . . .
>>And this also gets to the issue we discussed in the IF SC call
>>today. There is considerable misunderstanding and need for education
>>in the market place regarding the use and implementation of EDXL.
>>Part of this education is that EDXL is a transport mechanism and
>>must/can be viewed as independent from the technology implementation
>>infrastructure. It should not matter if the enterprise (in the
>>virtual sense) is implementing against a middleware bus, using
>>SOAP/WSDL/UDDI, using ebRIM/XML, using an OGC Catalog, using the
>>COMCARE EPAD application, using Java enterprise beans, etc. I view
>>EDXL as technology implementation neutral - as it should be.
>>Am I wrong in thinking this?
>>Also, my previous email was more about making sure that the
>>discussions in the EM TC on EDXL do not totally go totally US
>>DHS/DoD centric. I understand the immediate requirement but we
>>cannot loose sight of the bigger picture. For example, I would love
>>to be able to recommend EDXL to ORCHESTRA in Europe.
>>----- Original Message ----- From: "Rex Brooks" <rexb@starbourne.com>
>>To: "SIA Pilot-6" <sia-pilot6@humanml.cim3.net>; "Carl Reed OGC
>>Account" <creed@opengeospatial.org>; <emergency@lists.oasis-open.org>
>>Cc: "Haleftiras, Pericles" <phaleftiras@systechnologies.com>;
>>"Glaser, Ronald" <rfglase@sandia.gov>
>>Sent: Monday, March 20, 2006 5:33 PM
>>Subject: [emergency] Re: [sia-pilot6] [emergency] EDXL-DE routing
>>and valueListUrn
>>>I don't think Carl misunderstood that different valueListUrns are
>>>possible. Of course, I could be wrong, but I doubt it. I think
>>>Carl's concern is that some people may think that Dave's proposal
>>>was for a single valueListUrn. I do not think Dave is doing that. I
>>>think Dave is responding to the call for various groups to start
>>>producing, publishing and maintaining these necessary valueListUrns
>>>so that we can start using them in EDXL_DE routed messages.
>>>All of the international groups and constituencies mentioned need
>>>to be informed that it is now incumbent upon them to provide these
>>>semantic resources so that their systems, be they SensorNets or
>>>weatherAlerts, can be properly connected through our Emergency
>>>Response Networks.
>>>At 5:00 PM -0700 3/20/06, Ellis, David wrote:
>>>>Content-class: urn:content-classes:message
>>>>Content-Type: multipart/alternative;
>>>>All of scenarios you have proposed could use seperate valueListUrn
>>>>to control distribution of data within defined Area of
>>>>Responsiblities.  If transfer of data is needed between these
>>>>AORs, methods for exchanging messages are avaiable.  When can we
>>>>talk about this.  I believe all of your domain issues are
>>>>potential misunderstandings how routing is accomplished.
>>>>David E. Ellis
>>>>Information Management Architect
>>>>(505) 844-6697
>>>>From: Carl Reed OGC Account [mailto:creed@opengeospatial.org]
>>>>Sent: Mon 3/20/2006 4:20 PM
>>>>To: Ellis, David; SIA Pilot-6; emergency@lists.oasis-open.org
>>>>Cc: Harry Haury; Haleftiras, Pericles; Glaser, Ronald
>>>>Subject: Re: [emergency] EDXL-DE routing and valueListUrn
>>>>David -
>>>>While I understand the urgency and while I do not necessarily disagree
>>>> with
>>>>the contents of your slides on a National Effort for Emergency Data
>>>>Distribution, I would like to add a few words of caution.
>>>>First, what you have outlined are uses cases and requirements for one
>>>> domain
>>>>of use - alerts as related to secure US DoD sensor nets. I deal with
>>>> folks
>>>>doing sensor systems and networks in a number of other countries - all
>>>>civilian. Any of these applications using sensors can create alerts.
>>>> For
>>>>example, a new water portal in Canada that will send alerts based on
>>>> stream
>>>>flow gauges, traffic alerts being generated by the new generation of
>>>> ITS
>>>>capabilities, weather alerts, and systems function alerts being
>>>> generated by
>>>>transducers, and so forth. We cannot loose sight of all the other
>>>> potential
>>>>use cases that drives the requirements for EDXL - now and in the
>>>> future.
>>>>Second, and related to the first, is the fact that OASIS is an
>>>> international
>>>>standards organization. As such, we cannot ignore requirements for
>>>> using
>>>>EDXL that may be extremely viable in other countries. It is unfortunate
>>>> that
>>>>we have had little input from organizations in other countries that
>>>> have
>>>>requirements similar to the US DoD. That is why I am very pleased with
>>>> the
>>>>progress of the Sensor Standards Harmonization work that NIST is
>>>>Third, we would be remiss in ignoring the potential for alerts coming
>>>> from
>>>>the emerging sensor nets being designed, built, and fairly recently
>>>> deployed
>>>>for home systems and office buildings (office sensor networks are much
>>>> more
>>>>mature). See
>>>>well as all the work being done at UCLA (SOS) and Sun (SUN SPOT). These
>>>>systems are envisioned as being able to automatically generate alerts
>>>> (fire,
>>>>carbon monoxide, health, etc).
>>>>Finally, and anyone (someone) correct me if I am wrong, but perhaps the
>>>>COMCARE EPAD system would be a repository/registry solution.
>>>>So, I agree that current DHS and DoD requirements are very valid and
>>>> those
>>>>requirements must be answered by EDXL. But let's make sure we remain
>>>>balanced in our approach so that other communities outside DoD and DHS
>>>> are
>>>>also fairly represented at that CAP and EDXL have used well beyond.
>>>>----- Original Message -----
>>>>From: "Ellis, David" <dellis@sandia.gov>
>>>>To: "SIA Pilot-6" <sia-pilot6@humanml.cim3.net>;
>>>>Cc: "Harry Haury" <hhaury@nuparadigm.com>; "Haleftiras, Pericles"
>>>><phaleftiras@systechnologies.com>; "Glaser, Ronald"
>>>> <rfglase@sandia.gov>
>>>>Sent: Saturday, March 18, 2006 10:11 AM
>>>>Subject: [emergency] EDXL-DE routing and valueListUrn
>>>>I have a reasonably mature strategy for creating valueListUrn lists and
>>>>how they can be used to deploy a national architecture for Alerting and
>>>>Warning.  I have been trying to develop this to support Chips Disaster
>>>>Management efforts (e.g. EDXL-RM) and to allow for national sensor
>>>>capabilities (e.g. DNDO) to have the EDXL-DE routing system (execution
>>>>context) which provides the following capabilities:
>>>>1. Allow for establishment of Communities of Interest (COIs) where
>>>>appropriate authority can establish roles of entities, information
>>>>routing rules between them and issue certificate to ensure
>>>>authentication and authorization.
>>>>2. Permit interaction between COIs to instantiate robust MOUs enforced
>>>>by execution context allowing creation of national information grid.
>>>>3. Permit secure delivery of multiple levels of sensitive information
>>>>via signing, encryption and labeling within the EDXL-DE.
>>>>4. Allow abstraction of the implementation details (what) so national
>>>>planners can implement various operational concepts (documented in
>>>>DoDAF, FEA etc.) with minimal confusion on "how" it is accomplished.
>>>>I have tried to engage NIEM for over one year to explain these concepts
>>>>without success.  There is finally understanding between the various
>>>>standards organization on how important this is to major government
>>>>implementations.  On the other hand, major information providers are
>>>>claim our capabilities either don't exist or have never been
>>>>demonstrated.  Both are not true and in fact the EDXL-DE is being used
>>>>in an operational system within the DoD.  Unfortunately, it is not
>>>>branded as EDXL-DE since we have not issued the EDXL-DE OASIS standard
>>>>I need as many of the organization implementing EDXL-DE to attempt
>>>>sending outputs from your applications to the developing EDXL-DE
>>>> routing
>>>>capability at NuParadigm in Saint Louis or our capability at Sandia
>>>>National Laboratories.  Also, a generic ability to wrap CAP messages in
>>>>EDXL has been created and we need to discuss the security implications
>>>>of doing this from local applications or by the "execution context" for
>>>>legacy/warning-only CAP applications.
>>>>I need to be able to list all the capabilities of your applications
>>>> even
>>>>if they use explicated routing (e.g. DMIS COGs) and have no security
>>>>capability.  The design of our governments emerging national
>>>>capabilities is moving at lighting speed and EDXL-DE capabilities needs
>>>>to be a substantial portion of it.  Attached are two briefings present
>>>>this past week on sensor routing.
>>>>David E. Ellis
>>>>Information Management Architect
>>>>(505) 844-6697
>>>>-----Original Message-----
>>>>From: sia-pilot6-bounces@humanml.cim3.net
>>>>On Behalf Of Elysa Jones
>>>>Sent: Saturday, February 25, 2006 11:23 AM
>>>>To: Rex Brooks
>>>>Cc: sia-pilot6@humanml.cim3.net
>>>>Subject: Re: [sia-pilot6] [emergency] EDXL-DE Committee Draft
>>>>Yes, that is a good point.  I too want us to start coming up with these
>>>>"managed lists" knowing full well that NIEM wont be providing us
>>>>in the near term.  I had thought too that we could use the event list,
>>>>incident type, etc. that were provided in the original draft hand off
>>>> as
>>>>starting place.  Maybe we should put these in examples and put them in
>>>>cookbook?  I too think the Govt agencies will not step up to this for
>>>>time and I am glad the registry is being developed in the pilot.  We do
>>>>need another company though that can sign up for the "use" for the
>>>>committee specification phase.  I seem to be focused most these days on
>>>>jumping through the hoops for ratification.  Regards, Elysa
>>>>At 10:07 AM 2/25/2006, Rex Brooks wrote:
>>>>>Just to clarify, it isn't DMIS or IEM that needs to have a
>>>>> keyword/list
>>>>>place, but they do need to be using some values in those fields that
>>>>>be recognized and used by all of us, or by others that need and have
>>>>>permissions to do so. We didn't address that level of permissions, and
>>>>>doubt that anyone will start restricting these initial efforts, but it
>>>>>another place where security measures can be imposed if appropriate,
>>>>>since our pilot is building a registry where these pointers or the
>>>>>resources can reside, I wanted to mention it.  While I want to be fair
>>>>>gov agencies, I suspect they will have a more difficult time getting
>>>>>funding resources, considering the Congress' recent actions with
>>>>> regard
>>>>>"any" already approved E-Gov program movement of monies preparatory to
>>>>>actual spending, the chances are good that what the organizations in
>>>>>TC actually produce will be the default system for quite some time to
>>>>>come, so I want to suggest to everyone that they bear that in mind and
>>>>>approach work going forward in the next six months or so as if this
>>>>>be all the system there will be for the next year. Once what we build
>>>>>shows that it works, then I suspect there will quickly be a wealth of
>>>>>resources available.
>>>>>At 4:12 AM -0600 2/25/06, Elysa Jones wrote:
>>>>>>Hey Rex, Welcome back.  I hope your trip went well.  As for the 3
>>>>>>of the EDXL-DE, I think Sandia, IEM and DMIS volunteered to make the
>>>>>>statement about "use."  We wont be able to use Sandia though since
>>>>>>has an individual membership.  I'll put a note out to the list
>>>>>> shortly
>>>>>>ask who will be our third and if there is any keywords they must have
>>>>>>place.  Elysa
>>>>>>At 10:15 PM 2/24/2006, Rex Brooks wrote:
>>>>>>>Yes, this is all true,
>>>>>>>However, we still need 3 member organizations to vouch that they
>>>>>>>it as part of the move to an OASIS-wide vote, so we need to be
>>>>implmenting it.
>>>>>>>P.S. This means that we need to get an EventType Keyword/List and
>>>>>>>Sender/Recipient Keybord/List, etc, published by the appropriate
>>>>>>>>Hey Tim,
>>>>>>>>Yes, the next TC call is 3/9.  Whether we pull it now and make a
>>>>>>>>or wait until another round we could still not get it to a final
>>>>>>>>vote until May given the calendar process requirements. The
>>>>>>>>Draft has to be to OASIS for 5 business days before going to 15 day
>>>>>>>>review and must be back from 15 day review, comments addressed,
>>>>>>>>Committee Specification and back to OASIS by the 15th of the month
>>>>>>>>prior to the ratification vote.  We are on a tight schedule for a
>>>>>>>>the last 2 weeks of April even if we receive no substantive
>>>>>>>>Thanks for your input,
>>>>>>>>At 12:31 PM 2/22/2006, Tim Grapes wrote:
>>>>>>>>>Do I correctly recall that our next TC meeting won't be conducted
>>>>>>>>>March 9?  If so, I recommend we lay out our cards now in case
>>>>anyone feels
>>>>>>>>>the option to pull back and re-publish is warranted.
>>>>>>>>>My input is that this is simply a typo that can be corrected after
>>>>>>>>>15-day review.   However, if others feel the error truly is
>>>>substantive, I
>>>>>>>>>feel we should pull it back, make the correction, and republish
>>>>>>>>>than incurring an additional 15-day public comment.
>>>>>>>>>Tim Grapes
>>>>>>>>>Evolution Technologies, Inc.
>>>>>>>>>Disaster Management egov Initiative
>>>>>>>>>Science and Technology Directorate/OIC
>>>>>>>>>Department of Homeland Security
>>>>>>>>>Office:  (703) 654-6075
>>>>>>>>>Mobile:  (703) 304-4829
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: Elysa Jones
>>>>>>>>>Sent: Wednesday, February 22, 2006 1:06 PM
>>>>>>>>>To: emergency@lists.oasis-open.org
>>>>>>>>>Subject: [emergency] EDXL-DE Committee Draft
>>>>>>>>>TC Members,
>>>>>>>>>As discussed on our call yesterday, there are a couple of issues
>>>>with the
>>>>>>>>>EDXL-DE that have been brought to light from within the TC.  We
>>>>>>>>> are
>>>>>>>>>able to make any changes to the posted documents until after the
>>>>>>>>> 15
>>>>>>>>>review.  That review is schedule to end March 4.  The only
>>>>>>>>> comments
>>>>so far
>>>>>>>>>have come from within the TC although I fully expect some comments
>>>>as the
>>>>>>>>>end draws near.  The most significant comment is the problem with
>>>>>>>>>schema not matching the DOM.  The DOM is correct and the place
>>>>>>>>> most
>>>>>>>>>look for understanding of what is presented.
>>>>>>>>>I have discussed our situation with Mary McRae, our OASIS staff
>>>>contact to
>>>>>>>>>determine our most efficient method to proceed.  She said that if
>>>>in the
>>>>>>>>>mind of the TC, the schema would be considered non-normative, it
>>>>could be
>>>>>>>>>changed as any other typo or correction that is non-substantive
>>>>after the
>>>>>>>>>15-day review is complete.
>>>>>>>>>If we do feel that the correction of the schema is substantive,
>>>>>>>>>15-day comment period would be required.  In that case, we could
>>>>pull the
>>>>>>>>>current 15-day review, make the change and re-publish.  Or we
>>>>>>>>> could
>>>>>>>>>until this period is over, make our corrections and re-post for
>>>>>>>>>15-day review.  In either case, the document has to go to OASIS by
>>>>>>>>>of the month prior to the month of the vote.  With a successful
>>>>>>>>>review in this round, we will be able to submit to OASIS by the
>>>>15th of
>>>>>>>>>March and thus an OASIS wide vote the last 2 weeks of April.  A
>>>>>>>>>15-day review no matter how it happens will postpone the OASIS
>>>>>>>>> wide
>>>>>>>>>until the last 2 weeks of May.
>>>>>>>>>That is where we stand now and there is no real need for a
>>>>>>>>> decision
>>>>>>>>>point.  Please consider whether you feel the incorrect schema is
>>>>>>>>>substantive or not and let me know the will of the TC as to how we
>>>>>>>>>Elysa Jones
>>>>>>>>>Chair, OASIS EM-TC
>>>>>>>>>Engineering PRogram Manager
>>>>>>>>>Warning Systems, Inc.
>>>>>>>>>To unsubscribe from this mail list, you must leave the OASIS TC
>>>>>>>>>generates this mail.  You may a link to this group and all your
>>>>>>>>> TCs
>>>>>>>>>No virus found in this incoming message.
>>>>>>>>>Checked by AVG Free Edition.
>>>>>>>>>Version: 7.1.375 / Virus Database: 268.0.0/266 - Release Date:
>>>>>>>>>No virus found in this outgoing message.
>>>>>>>>>Checked by AVG Free Edition.
>>>>>>>>>Version: 7.1.375 / Virus Database: 268.0.0/266 - Release Date:
>>>>>>>>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
>>>>>>>Rex Brooks
>>>>>>>President, CEO
>>>>>>>Starbourne Communications Design
>>>>>>>GeoAddress: 1361-A Addison
>>>>>>>Berkeley, CA 94702
>>>>>>>Tel: 510-849-2309
>>>>>Rex Brooks
>>>>>President, CEO
>>>>>Starbourne Communications Design
>>>>>GeoAddress: 1361-A Addison
>>>>>Berkeley, CA 94702
>>>>>Tel: 510-849-2309
>>>>  _________________________________________________________________
>>>>Message Archives:
>>>>To Post:
>>>>Shared Files:
>>>>CWE Portal: <http://humanml.cim3.net/>http://humanml.cim3.net/
>>>>Community Wiki:
>>>> <http://humanml.cim3.net/wiki/>http://humanml.cim3.net/wiki/
>>>>>  ---------------------------------------------------------------------
>>>>  > 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:
>>>>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
>>>>  _________________________________________________________________
>>>>Message Archives: http://humanml.cim3.net/forum/sia-pilot6/
>>>>To Post: mailto:sia-pilot6@humanml.cim3.net
>>>>Shared Files: http://humanml.cim3.net/file/work/project/sia-pilot6/
>>>>CWE Portal: http://humanml.cim3.net/
>>>>Community Wiki: http://humanml.cim3.net/wiki/
>>>Rex Brooks
>>>President, CEO
>>>Starbourne Communications Design
>>>GeoAddress: 1361-A Addison
>>>Berkeley, CA 94702
>>>Tel: 510-849-2309
>>>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
>>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
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309

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