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] Extension Status


Thanks Doug,

We took the decision long ago to use default lists as a way to encourage communities to develop whatever lists they need since no one but your Canadian brethren had done that. As I recall, we made it a stipulation to only supply default lists for required elements. I suspect that it will be a difficult decision to overturn.

However, I believe that this should be an EDXL discussion, not a CAP discussion. We also took the decision long ago to include CAP in EDXL, reversal of which may be a decision for which it would easier to achieve consensus. I could be persuaded that the needs of the many involved with CAP might be better served by keeping it explicitly distinct from EDXL.

Its something to think about, Folks.

Cheers,
Rex






On 5/6/2013 9:41 AM, Doug Allport wrote:
I'm thinking we might be missing one: List Definition - community defines a list of values. 

I'm looking at #1 as covering the addition of new data elements. e.g. The CAPAN CAP Event Location Layer defines CAP <valueName>s for use when including the actual location of the subject event.  

#2, 3, and 4 speak to working with a default list, something I'm not very comfortable with.

What I believe is missing, is defining a list for an existing data element for which no values are defined by the standard. e.g. CAP-CP defines a list of <eventCode> and <geocode> values. 

Perhaps this is covered by #1, and if so I suggest we should differentiate the use cases with two items in the list. 

Cheers,
Doug

Doug Allport
Executive Director (Volunteer)
Canadian Association for Public Alerting and Notification (www.CAPAN.ca)
(613) 271-1040 Office
(613) 294-4425 Mobile

 




From: Elysa Jones <ElysaJones@yahoo.com>
Date: Monday, 6 May, 2013 11:59 AM
To: "rex.brooks@ncoic.org" <rex.brooks@ncoic.org>, "emergency@lists.oasis-open.org" <emergency@lists.oasis-open.org>
Subject: RE: [emergency] Extension Status

Hi Brian,

 

Thanks for putting this together for review and consideration.  I encourage ALL EM-TC members to review what has been provided by Brian and be prepared to discuss.  This will have relevance to ALL of our EDXL work.  If as you review, you feel there is more information or time needed please respond back to this email ASAP.  I do not want to rush this but want to move it along smartly as this needs to be decided before we can move forward with DE 2.0 and SitRep 1.0.

 

Cheers,

Elysa

 

From: emergency@lists.oasis-open.org [mailto:emergency@lists.oasis-open.org] On Behalf Of Rex Brooks
Sent: Monday, May 06, 2013 9:42 AM
To: emergency@lists.oasis-open.org
Subject: Re: [emergency] Extension Status

 

Thanks Brian,

This looks good to me.

Cheers,
Rex

On 5/6/2013 5:48 AM, Wilkins, Brian M wrote:

Elysa,

 

Here is where I think we are at with the Extension discussion.

 

We have a potential schema and set of use cases that need to be discussed.  I have attached the latest schema for reference.  Here are the current use cases that have been identified so far:

1.       Standard augmentation –community adds additional data to the standard

2.       List augmentation – community adds to a default list of values

3.       List replacement – community replaces a default list of values

4.       List redefinition – community redefines a default list of values

5.       Translation – community translates fields to new format/standard (think TEP -> HL7)

 

What are the next steps?

1.       Determine if these are the right use cases and/or if there are any missing use cases

2.       Determine if the proposed schema satisfies the identified set of use cases

3.       Determine if the proposed schema satisfies any profiles currently in use

4.       Develop guidance for extension use in the various sub-committees

5.       Develop guidance for extension use by the developer/adopter

 

If anyone thinks I have missed anything, please let us know.

 

Brian M Wilkins

Lead Software Systems Engineer

The MITRE Corporation

bwilkins@mitre.org

office: 781-271-2332

cell: 781-710-2617

 




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




-- 
Rex Brooks
GeoAddress: 
1361-A Addison
Berkeley, CA 94702
Phone: 510-898-0670


-- 
Rex Brooks
GeoAddress: 
1361-A Addison
Berkeley, CA 94702
Phone: 510-898-0670


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