Next in thread → Next in month →

Re: [emergency-if] EDXL-DE 2.0 schema changes proposed at TCIP F2F meeting

From
Rob Torchon <>
Date
2010-03-04T18:18:00+00:00
ID
Thread
Re: [emergency-if] EDXL-DE 2.0 schema changes proposed at TCIP F2F meeting
Would this be best handled in the GIS subcommittee?



Rob







From: McGarry, Donald P.
[mailto:]

Sent: Thursday, March 04, 2010 4:06 AM

To: Hans Jespersen; ;


Subject: RE: [emergency-if] EDXL-DE 2.0 schema changes proposed at TCIP
F2F meeting







I would be interested in assisting with this effort.  Let
me know if we should setup a time to chat outside of the IF to come up with a
plan…





-Don

Office: 315-838-2669

Cell: 315-383-1197











From: Hans Jespersen
[mailto:]

Sent: Wednesday, March 03, 2010 1:47 AM

To: ; 

Subject: Re: [emergency-if] EDXL-DE 2.0 schema changes proposed at TCIP
F2F meeting







I agree. Let's figure out a way to make <targetArea> more
extensible in order to support other pre-defined boundaries like FIPS and
Canadian SGC and not just be limited to UN Locodes.


-hans

--

Hans Jespersen

(650) 924-2674







From: Doug Allport

To: 

Sent: Tue Mar 02 22:03:58 2010

Subject: RE: [emergency-if] EDXL-DE 2.0 schema changes proposed at TCIP
F2F meeting 

Hans



I believe locCodeUN was to allow for a user
defined valueName and values consistent with CAP. You may recall I was making
the case for FIPS and Canadian SGC use. 





Cheers,



Doug Allport

Executive Director

Canadian Association for Public Alerting
and Notification (CAPAN)




(613) 271-1040 Tel

(613) 294-4425 Blackberry

www.CAPAN.ca











From: Hans Jespersen
[mailto:]

Sent: March-02-10 12:57 AM

To: 

Subject: [emergency-if] EDXL-DE 2.0 schema changes proposed at TCIP F2F
meeting







I took a crack at updating the older strawman EDXL-DE 1.1
spec (attached) to reflect the changes I committed to making at the TCIP show F2F.




The changes were as follows:



-       I
made the spec into version 2.0 instead of version 1.1

-       I
changed the type of the newly added <replyTo> and <errorTo>
elements to be the same complex type as the element <explictAddress>
(which is a type called “valueSchemeType”)

-       I
removed the complex types “replyToType” and “authenticationType”
since they are no longer used for the <replyTo> and
<errorTo> elements

-       I
moved <replyTo> and <errorTo> elements down to appear just after
<explicitAddress> since the elements must appear in a specific order
(being that they are defined as a sequence) and it makes more sense to group
all the explicitAddress(es) together

-       I
changed the <xmlContent> element name to <contentXML> so it would
be compliant with the xml naming rules. I also renamed the complex type from
“xmlContentType” to “contentXMLType” to be consistent (and just in case there
are similar naming rules for types as well)



I think that reflects all the schema changes I was tasked
with. I do have other action items which we can discuss on the call today (Mar 02)



-hans



-- 

Hans Jespersen

Principal Systems Engineer

Solace Systems Inc.

2051 Landings Drive, Mountain View, CA 94043

Phone: (650) 924-2670



http://www.solacesystems.com
Next in thread → Next in month →