OASIS Emergency Management TC

Friends,   We have worked hard getting SitRep1 and DE2 ready for an organizational vote and we currently have a ballot open for the purpose of approving these works as a Committee Specification.  If this passes, the next steps are obtaining statements of use then agreeing (again by special majority) to begin the 60-day review prior to organizational wide balloting.    Discussion over the past several months regarding a “standard” extension method for all of our specifications has been ongoing.  These discussion are best documented in the RIM-SC.  TC members have been made aware of this discussion and invited to participate and stay in touch as it could affect all of our work.  I’ll not repeat any of that discussion here but ask you to keep it in mind as you make your decision about SitRep1 and DE2.   You may recall there were two versions of the DE2 being worked – one with the layer-extension concept and one without.  We decided to go forward without at this time but all agreed we should keep it in mind and find some way to incorporate later - perhaps through common types.  Some of our members are concerned with releasing DE (as well as SitRep) without this extension concept and then trying to make a change later would be problematic.  We all know how long changes can take and we are anxious to get this work out.  We learned in the last couple of weeks that this extension method would solve some issues with TEP as well.  So, after considering putting this in TEP, it has re-opened the discussion about DE and SitRep in some circles.   The bottom line here is that we have members that are re-thinking whether we need to put either of these standards out without this extension concept.  We have sufficient votes today to move the as they are to Committee Specification.  The ballot closes tomorrow.  If we wish to add “extensions” to DE2 and SitRep, we will have to make not only changes to the document and back through public review again.   Personally, having a “standardized” extension method across all our standards is very appealing to me.  However, delaying SitRep and DE2 concerns me if it is going to take another year.  If it can be completed in 6 months, it concerns me a little less - but only if sufficient resources are available to turn this around quickly.  Basically DE2 has already been done and there is a WD version with it included.  I’m not sure about how much time it would take to add it to SitRep.   Please respond to this note with your thoughts.   Regards,   Elysa Jones, Chair  

Elysa,   I understand the concern with delaying DE2 and SitRep.  There has been a lot of time and effort in getting those standards to this point. However, I feel we are not that far off from having a wider acceptance of the most recent Extension concept.  As you noted, it is being added to TEP.  It is also being added to HAVE2 and should be considered for TEC.  I am optimistic that we could get agreement on the use of Extensions in DE2 and SitRep in fairly short order (few weeks, month or so).  I would be concerned that adopters of DE2 and SitRep as they now stand will: 1. Waste time and effort implementing a standard that will be changed in the relatively near time, since the new schema will not be backwards compatible and 2. The current Choice mechanism is more complicated and may not meet community needs.  I would be willing to volunteer some more time over the next few months to help drive this forward, if that helps.    Brian M Wilkins Lead Software Systems Engineer The MITRE Corporation       From: emergency@lists.oasis-open.org [mailto:emergency@lists.oasis-open.org] On Behalf Of Elysa Jones Sent: Wednesday, April 10, 2013 2:19 PM To: emergency@lists.oasis-open.org Subject: [emergency] Thoughts on EDXL-DE and SitRep Importance: High   Friends,   We have worked hard getting SitRep1 and DE2 ready for an organizational vote and we currently have a ballot open for the purpose of approving these works as a Committee Specification.  If this passes, the next steps are obtaining statements of use then agreeing (again by special majority) to begin the 60-day review prior to organizational wide balloting.    Discussion over the past several months regarding a “standard” extension method for all of our specifications has been ongoing.  These discussion are best documented in the RIM-SC.  TC members have been made aware of this discussion and invited to participate and stay in touch as it could affect all of our work.  I’ll not repeat any of that discussion here but ask you to keep it in mind as you make your decision about SitRep1 and DE2.   You may recall there were two versions of the DE2 being worked – one with the layer-extension concept and one without.  We decided to go forward without at this time but all agreed we should keep it in mind and find some way to incorporate later - perhaps through common types.  Some of our members are concerned with releasing DE (as well as SitRep) without this extension concept and then trying to make a change later would be problematic.  We all know how long changes can take and we are anxious to get this work out.  We learned in the last couple of weeks that this extension method would solve some issues with TEP as well.  So, after considering putting this in TEP, it has re-opened the discussion about DE and SitRep in some circles.   The bottom line here is that we have members that are re-thinking whether we need to put either of these standards out without this extension concept.  We have sufficient votes today to move the as they are to Committee Specification.  The ballot closes tomorrow.  If we wish to add “extensions” to DE2 and SitRep, we will have to make not only changes to the document and back through public review again.   Personally, having a “standardized” extension method across all our standards is very appealing to me.  However, delaying SitRep and DE2 concerns me if it is going to take another year.  If it can be completed in 6 months, it concerns me a little less - but only if sufficient resources are available to turn this around quickly.  Basically DE2 has already been done and there is a WD version with it included.  I’m not sure about how much time it would take to add it to SitRep.   Please respond to this note with your thoughts.   Regards,   Elysa Jones, Chair  

I would agree with Brian on 2 main points If its not backwards compatible, why would anyone adopt the new release? It takes a long period of time to get acceptance and adoption. This concept is a major enhancement to all our standards. While I have not been part of the discussions, I remember when it started in HAVE and the major effect it would have in flexibility in keeping all standards viable even as new elements are demanded. In the case of SitReps especially, there is not a complete standard in data collection, and while it covers a broad area of report types, each of those report types cover the basics only. When SitReps are used, various reporting agencies and jurisdictions will have their own tweaks of data elements. As to the extra time required, if the extension structure SUPPLEMENTS but does not change the base SitReps schema, then we will not have to re-validate SitReps, only the extension. This should cut down the release time maybe as little as 3-4 months. I cannot speak to the extensions effect on DE, but I would entertain the notion of leaving it out. The idea behind the extensions was to allow extra data to be included without breaking validation. This capability is crucial for StiReps, can be easily included in HAVE, and would be an excellent addition to CAP.   Thanks Rob 805-551-6232 From: Wilkins, Brian M <bwilkins@mitre.org> To: emergency@lists.oasis-open.org <emergency@lists.oasis-open.org> Sent: Wednesday, April 10, 2013 11:35 AM Subject: RE: [emergency] Thoughts on EDXL-DE and SitRep Elysa,   I understand the concern with delaying DE2 and SitRep.  There has been a lot of time and effort in getting those standards to this point. However, I feel we are not that far off from having a wider acceptance of the most recent Extension concept.  As you noted, it is being added to TEP.  It is also being added to HAVE2 and should be considered for TEC.  I am optimistic that we could get agreement on the use of Extensions in DE2 and SitRep in fairly short order (few weeks, month or so).  I would be concerned that adopters of DE2 and SitRep as they now stand will: 1. Waste time and effort implementing a standard that will be changed in the relatively near time, since the new schema will not be backwards compatible and 2. The current Choice mechanism is more complicated and may not meet community needs.  I would be willing to volunteer some more time over the next few months to help drive this forward, if that helps.    Brian M Wilkins Lead Software Systems Engineer The MITRE Corporation       From: emergency@lists.oasis-open.org [mailto:emergency@lists.oasis-open.org] On Behalf Of Elysa Jones Sent: Wednesday, April 10, 2013 2:19 PM To: emergency@lists.oasis-open.org Subject: [emergency] Thoughts on EDXL-DE and SitRep Importance: High   Friends,   We have worked hard getting SitRep1 and DE2 ready for an organizational vote and we currently have a ballot open for the purpose of approving these works as a Committee Specification.  If this passes, the next steps are obtaining statements of use then agreeing (again by special majority) to begin the 60-day review prior to organizational wide balloting.    Discussion over the past several months regarding a “standard” extension method for all of our specifications has been ongoing.  These discussion are best documented in the RIM-SC.  TC members have been made aware of this discussion and invited to participate and stay in touch as it could affect all of our work.  I’ll not repeat any of that discussion here but ask you to keep it in mind as you make your decision about SitRep1 and DE2.   You may recall there were two versions of the DE2 being worked – one with the layer-extension concept and one without.  We decided to go forward without at this time but all agreed we should keep it in mind and find some way to incorporate later - perhaps through common types.  Some of our members are concerned with releasing DE (as well as SitRep) without this extension concept and then trying to make a change later would be problematic.  We all know how long changes can take and we are anxious to get this work out.  We learned in the last couple of weeks that this extension method would solve some issues with TEP as well.  So, after considering putting this in TEP, it has re-opened the discussion about DE and SitRep in some circles.   The bottom line here is that we have members that are re-thinking whether we need to put either of these standards out without this extension concept.  We have sufficient votes today to move the as they are to Committee Specification.  The ballot closes tomorrow.  If we wish to add “extensions” to DE2 and SitRep, we will have to make not only changes to the document and back through public review again.   Personally, having a “standardized” extension method across all our standards is very appealing to me.  However, delaying SitRep and DE2 concerns me if it is going to take another year.  If it can be completed in 6 months, it concerns me a little less - but only if sufficient resources are available to turn this around quickly.  Basically DE2 has already been done and there is a WD version with it included.  I’m not sure about how much time it would take to add it to SitRep.   Please respond to this note with your thoughts.   Regards,   Elysa Jones, Chair  

I don't think we need to do more than add an errata, and we can do that for RM v1.0 at the same as for DE2.0 and SitRep1.0. Going back into all of those elements, especially since many of them in SitRep are in my opinion more than we need to be explicit about --- is just not going to be a few months because if we're gonna do it right we might as well hold out for perfection....okay I don't really mean that. Just makin' a point. Let's NOT make the perfect the enemy of the good enough. Cheers, Rex On 4/10/2013 11:35 AM, Wilkins, Brian M wrote: Elysa,   I understand the concern with delaying DE2 and SitRep.  There has been a lot of time and effort in getting those standards to this point. However, I feel we are not that far off from having a wider acceptance of the most recent Extension concept.  As you noted, it is being added to TEP.  It is also being added to HAVE2 and should be considered for TEC.  I am optimistic that we could get agreement on the use of Extensions in DE2 and SitRep in fairly short order (few weeks, month or so).  I would be concerned that adopters of DE2 and SitRep as they now stand will: 1. Waste time and effort implementing a standard that will be changed in the relatively near time, since the new schema will not be backwards compatible and 2. The current Choice mechanism is more complicated and may not meet community needs.  I would be willing to volunteer some more time over the next few months to help drive this forward, if that helps.    Brian M Wilkins Lead Software Systems Engineer The MITRE Corporation       From: emergency@lists.oasis-open.org [ mailto:emergency@lists.oasis-open.org ] On Behalf Of Elysa Jones Sent: Wednesday, April 10, 2013 2:19 PM To: emergency@lists.oasis-open.org Subject: [emergency] Thoughts on EDXL-DE and SitRep Importance: High   Friends,   We have worked hard getting SitRep1 and DE2 ready for an organizational vote and we currently have a ballot open for the purpose of approving these works as a Committee Specification.  If this passes, the next steps are obtaining statements of use then agreeing (again by special majority) to begin the 60-day review prior to organizational wide balloting.    Discussion over the past several months regarding a “standard” extension method for all of our specifications has been ongoing.  These discussion are best documented in the RIM-SC.  TC members have been made aware of this discussion and invited to participate and stay in touch as it could affect all of our work.  I’ll not repeat any of that discussion here but ask you to keep it in mind as you make your decision about SitRep1 and DE2.   You may recall there were two versions of the DE2 being worked – one with the layer-extension concept and one without.  We decided to go forward without at this time but all agreed we should keep it in mind and find some way to incorporate later - perhaps through common types.  Some of our members are concerned with releasing DE (as well as SitRep) without this extension concept and then trying to make a change later would be problematic.  We all know how long changes can take and we are anxious to get this work out.  We learned in the last couple of weeks that this extension method would solve some issues with TEP as well.  So, after considering putting this in TEP, it has re-opened the discussion about DE and SitRep in some circles.   The bottom line here is that we have members that are re-thinking whether we need to put either of these standards out without this extension concept.  We have sufficient votes today to move the as they are to Committee Specification.  The ballot closes tomorrow.  If we wish to add “extensions” to DE2 and SitRep, we will have to make not only changes to the document and back through public review again.   Personally, having a “standardized” extension method across all our standards is very appealing to me.  However, delaying SitRep and DE2 concerns me if it is going to take another year.  If it can be completed in 6 months, it concerns me a little less - but only if sufficient resources are available to turn this around quickly.  Basically DE2 has already been done and there is a WD version with it included.  I’m not sure about how much time it would take to add it to SitRep.   Please respond to this note with your thoughts.   Regards,   Elysa Jones, Chair   -- Rex Brooks GeoAddress: 1361-A Addison Berkeley, CA 94702 Phone: 510-898-0670

Folks, I am going to accept whatever you folks all agree on this time. I like the draft de 2.0.  I like extensions as well.  What I would not like is extensions to extend everything by another year.  So, MITRE guys, if you want 'em, fix the document to include them, and fix it in the next two months (that means COMPLETED and ready for publication).  If you are willing and able to commit to that. I will support you. Otherwise, lets just go with what we have. vr Gary Ham (CTR) Contractor via CACI FEMA/NCP IPAWS Systems Architect, IPAWS-OPEN  Mobile Phone: 703-899-6241 e-mail:  gham@grandpaham.com On Apr 10, 2013, at 3:02 PM, Rex Brooks < rex.brooks@ncoic.org > wrote: I don't think we need to do more than add an errata, and we can do that for RM v1.0 at the same as for DE2.0 and SitRep1.0. Going back into all of those elements, especially since many of them in SitRep are in my opinion more than we need to be explicit about --- is just not going to be a few months because if we're gonna do it right we might as well hold out for perfection....okay I don't really mean that. Just makin' a point. Let's NOT make the perfect the enemy of the good enough. Cheers, Rex On 4/10/2013 11:35 AM, Wilkins, Brian M wrote: Elysa,   I understand the concern with delaying DE2 and SitRep.  There has been a lot of time and effort in getting those standards to this point. However, I feel we are not that far off from having a wider acceptance of the most recent Extension concept.  As you noted, it is being added to TEP.  It is also being added to HAVE2 and should be considered for TEC.  I am optimistic that we could get agreement on the use of Extensions in DE2 and SitRep in fairly short order (few weeks, month or so).  I would be concerned that adopters of DE2 and SitRep as they now stand will: 1. Waste time and effort implementing a standard that will be changed in the relatively near time, since the new schema will not be backwards compatible and 2. The current Choice mechanism is more complicated and may not meet community needs.  I would be willing to volunteer some more time over the next few months to help drive this forward, if that helps.    Brian M Wilkins Lead Software Systems Engineer The MITRE Corporation       From: emergency@lists.oasis-open.org [ mailto:emergency@lists.oasis-open.org ] On Behalf Of Elysa Jones Sent: Wednesday, April 10, 2013 2:19 PM To: emergency@lists.oasis-open.org Subject: [emergency] Thoughts on EDXL-DE and SitRep Importance: High   Friends,   We have worked hard getting SitRep1 and DE2 ready for an organizational vote and we currently have a ballot open for the purpose of approving these works as a Committee Specification.  If this passes, the next steps are obtaining statements of use then agreeing (again by special majority) to begin the 60-day review prior to organizational wide balloting.    Discussion over the past several months regarding a “standard” extension method for all of our specifications has been ongoing.  These discussion are best documented in the RIM-SC.  TC members have been made aware of this discussion and invited to participate and stay in touch as it could affect all of our work.  I’ll not repeat any of that discussion here but ask you to keep it in mind as you make your decision about SitRep1 and DE2.   You may recall there were two versions of the DE2 being worked – one with the layer-extension concept and one without.  We decided to go forward without at this time but all agreed we should keep it in mind and find some way to incorporate later - perhaps through common types.  Some of our members are concerned with releasing DE (as well as SitRep) without this extension concept and then trying to make a change later would be problematic.  We all know how long changes can take and we are anxious to get this work out.  We learned in the last couple of weeks that this extension method would solve some issues with TEP as well.  So, after considering putting this in TEP, it has re-opened the discussion about DE and SitRep in some circles.   The bottom line here is that we have members that are re-thinking whether we need to put either of these standards out without this extension concept.  We have sufficient votes today to move the as they are to Committee Specification.  The ballot closes tomorrow.  If we wish to add “extensions” to DE2 and SitRep, we will have to make not only changes to the document and back through public review again.   Personally, having a “standardized” extension method across all our standards is very appealing to me.  However, delaying SitRep and DE2 concerns me if it is going to take another year.  If it can be completed in 6 months, it concerns me a little less - but only if sufficient resources are available to turn this around quickly.  Basically DE2 has already been done and there is a WD version with it included.  I’m not sure about how much time it would take to add it to SitRep.   Please respond to this note with your thoughts.   Regards,   Elysa Jones, Chair   -- Rex Brooks GeoAddress: 1361-A Addison Berkeley, CA 94702 Phone: 510-898-0670

There is an old saying that if it isn't forbidden, it's mandatory. That is a deliberately extreme notion, but, to be honest, I don't think we need to expicitly state that extension can apply to SitRep and DE, or HAVE and RM for that matter. If we make the change to the edxl-ct, edxl-gsf or edxl-ciq it applies and all we really need to do is to provide some guidance. I absolutely oppose pulling back on SitRep-v1.0 or DE-v2.0. I could have been equivocal, but where's the fun in that? ;-) Cheers, Rex On 4/10/2013 11:18 AM, Elysa Jones wrote: Friends,   We have worked hard getting SitRep1 and DE2 ready for an organizational vote and we currently have a ballot open for the purpose of approving these works as a Committee Specification.  If this passes, the next steps are obtaining statements of use then agreeing (again by special majority) to begin the 60-day review prior to organizational wide balloting.    Discussion over the past several months regarding a “standard” extension method for all of our specifications has been ongoing.  These discussion are best documented in the RIM-SC.  TC members have been made aware of this discussion and invited to participate and stay in touch as it could affect all of our work.  I’ll not repeat any of that discussion here but ask you to keep it in mind as you make your decision about SitRep1 and DE2.   You may recall there were two versions of the DE2 being worked – one with the layer-extension concept and one without.  We decided to go forward without at this time but all agreed we should keep it in mind and find some way to incorporate later - perhaps through common types.  Some of our members are concerned with releasing DE (as well as SitRep) without this extension concept and then trying to make a change later would be problematic.  We all know how long changes can take and we are anxious to get this work out.  We learned in the last couple of weeks that this extension method would solve some issues with TEP as well.  So, after considering putting this in TEP, it has re-opened the discussion about DE and SitRep in some circles.   The bottom line here is that we have members that are re-thinking whether we need to put either of these standards out without this extension concept.  We have sufficient votes today to move the as they are to Committee Specification.  The ballot closes tomorrow.  If we wish to add “extensions” to DE2 and SitRep, we will have to make not only changes to the document and back through public review again.   Personally, having a “standardized” extension method across all our standards is very appealing to me.  However, delaying SitRep and DE2 concerns me if it is going to take another year.  If it can be completed in 6 months, it concerns me a little less - but only if sufficient resources are available to turn this around quickly.  Basically DE2 has already been done and there is a WD version with it included.  I’m not sure about how much time it would take to add it to SitRep.   Please respond to this note with your thoughts.   Regards,   Elysa Jones, Chair   -- Rex Brooks GeoAddress: 1361-A Addison Berkeley, CA 94702 Phone: 510-898-0670

Extensions should be part of common types so it would be available to any standard using common types.  However, it is still up to any individual standard to allow extensions or not. If they are not part of the schema for the standard, then they are not part of the standard and any adopter trying to add them to a given standard will break interoperability. This in itself explicitly states whether or not Extensions are part of a standard.  If this change is implemented as being suggested, this will not be a minor change to the schema, satisfied by an Errata.  This will remove the choice elements and add a whole new element in possibly many places in addition to adding potentially multiple sets of enumerations.  Someone that implements DE2 as it is today will have to make significant changes to their code base to implement DE X with extensions, or SitRep for that matter.  As both an implementer and a standards member, I think it is in the best interest of our communities to wait, make the changes, and help limit that pain/cost of implementation. IMHO.   V/R, Brian     From: emergency@lists.oasis-open.org [mailto:emergency@lists.oasis-open.org] On Behalf Of Rex Brooks Sent: Wednesday, April 10, 2013 2:55 PM To: emergency@lists.oasis-open.org Subject: Re: [emergency] Thoughts on EDXL-DE and SitRep   There is an old saying that if it isn't forbidden, it's mandatory. That is a deliberately extreme notion, but, to be honest, I don't think we need to expicitly state that extension can apply to SitRep and DE, or HAVE and RM for that matter. If we make the change to the edxl-ct, edxl-gsf or edxl-ciq it applies and all we really need to do is to provide some guidance. I absolutely oppose pulling back on SitRep-v1.0 or DE-v2.0. I could have been equivocal, but where's the fun in that? ;-) Cheers, Rex On 4/10/2013 11:18 AM, Elysa Jones wrote: Friends,   We have worked hard getting SitRep1 and DE2 ready for an organizational vote and we currently have a ballot open for the purpose of approving these works as a Committee Specification.  If this passes, the next steps are obtaining statements of use then agreeing (again by special majority) to begin the 60-day review prior to organizational wide balloting.    Discussion over the past several months regarding a “standard” extension method for all of our specifications has been ongoing.  These discussion are best documented in the RIM-SC.  TC members have been made aware of this discussion and invited to participate and stay in touch as it could affect all of our work.  I’ll not repeat any of that discussion here but ask you to keep it in mind as you make your decision about SitRep1 and DE2.   You may recall there were two versions of the DE2 being worked – one with the layer-extension concept and one without.  We decided to go forward without at this time but all agreed we should keep it in mind and find some way to incorporate later - perhaps through common types.  Some of our members are concerned with releasing DE (as well as SitRep) without this extension concept and then trying to make a change later would be problematic.  We all know how long changes can take and we are anxious to get this work out.  We learned in the last couple of weeks that this extension method would solve some issues with TEP as well.  So, after considering putting this in TEP, it has re-opened the discussion about DE and SitRep in some circles.   The bottom line here is that we have members that are re-thinking whether we need to put either of these standards out without this extension concept.  We have sufficient votes today to move the as they are to Committee Specification.  The ballot closes tomorrow.  If we wish to add “extensions” to DE2 and SitRep, we will have to make not only changes to the document and back through public review again.   Personally, having a “standardized” extension method across all our standards is very appealing to me.  However, delaying SitRep and DE2 concerns me if it is going to take another year.  If it can be completed in 6 months, it concerns me a little less - but only if sufficient resources are available to turn this around quickly.  Basically DE2 has already been done and there is a WD version with it included.  I’m not sure about how much time it would take to add it to SitRep.   Please respond to this note with your thoughts.   Regards,   Elysa Jones, Chair   -- Rex Brooks GeoAddress: 1361-A Addison Berkeley, CA 94702 Phone: 510-898-0670

Okay, I'll give it some more thought, but I'm  not happy about waiting. Cheers, Rex On 4/10/2013 12:11 PM, Wilkins, Brian M wrote: Extensions should be part of common types so it would be available to any standard using common types.  However, it is still up to any individual standard to allow extensions or not. If they are not part of the schema for the standard, then they are not part of the standard and any adopter trying to add them to a given standard will break interoperability. This in itself explicitly states whether or not Extensions are part of a standard.  If this change is implemented as being suggested, this will not be a minor change to the schema, satisfied by an Errata.  This will remove the choice elements and add a whole new element in possibly many places in addition to adding potentially multiple sets of enumerations.  Someone that implements DE2 as it is today will have to make significant changes to their code base to implement DE X with extensions, or SitRep for that matter.  As both an implementer and a standards member, I think it is in the best interest of our communities to wait, make the changes, and help limit that pain/cost of implementation. IMHO.   V/R, Brian     From: emergency@lists.oasis-open.org [ mailto:emergency@lists.oasis-open.org ] On Behalf Of Rex Brooks Sent: Wednesday, April 10, 2013 2:55 PM To: emergency@lists.oasis-open.org Subject: Re: [emergency] Thoughts on EDXL-DE and SitRep   There is an old saying that if it isn't forbidden, it's mandatory. That is a deliberately extreme notion, but, to be honest, I don't think we need to expicitly state that extension can apply to SitRep and DE, or HAVE and RM for that matter. If we make the change to the edxl-ct, edxl-gsf or edxl-ciq it applies and all we really need to do is to provide some guidance. I absolutely oppose pulling back on SitRep-v1.0 or DE-v2.0. I could have been equivocal, but where's the fun in that? ;-) Cheers, Rex On 4/10/2013 11:18 AM, Elysa Jones wrote: Friends,   We have worked hard getting SitRep1 and DE2 ready for an organizational vote and we currently have a ballot open for the purpose of approving these works as a Committee Specification.  If this passes, the next steps are obtaining statements of use then agreeing (again by special majority) to begin the 60-day review prior to organizational wide balloting.    Discussion over the past several months regarding a “standard” extension method for all of our specifications has been ongoing.  These discussion are best documented in the RIM-SC.  TC members have been made aware of this discussion and invited to participate and stay in touch as it could affect all of our work.  I’ll not repeat any of that discussion here but ask you to keep it in mind as you make your decision about SitRep1 and DE2.   You may recall there were two versions of the DE2 being worked – one with the layer-extension concept and one without.  We decided to go forward without at this time but all agreed we should keep it in mind and find some way to incorporate later - perhaps through common types.  Some of our members are concerned with releasing DE (as well as SitRep) without this extension concept and then trying to make a change later would be problematic.  We all know how long changes can take and we are anxious to get this work out.  We learned in the last couple of weeks that this extension method would solve some issues with TEP as well.  So, after considering putting this in TEP, it has re-opened the discussion about DE and SitRep in some circles.   The bottom line here is that we have members that are re-thinking whether we need to put either of these standards out without this extension concept.  We have sufficient votes today to move the as they are to Committee Specification.  The ballot closes tomorrow.  If we wish to add “extensions” to DE2 and SitRep, we will have to make not only changes to the document and back through public review again.   Personally, having a “standardized” extension method across all our standards is very appealing to me.  However, delaying SitRep and DE2 concerns me if it is going to take another year.  If it can be completed in 6 months, it concerns me a little less - but only if sufficient resources are available to turn this around quickly.  Basically DE2 has already been done and there is a WD version with it included.  I’m not sure about how much time it would take to add it to SitRep.   Please respond to this note with your thoughts.   Regards,   Elysa Jones, Chair   -- 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

Ok, maybe I can put some order into all this: 1) Let's move the new candidate standards with updated schema and adjusted specification (DE 2.0, TEP 1.0) proceed through the approval process; 2) Validate the "Extension" mechanisms and get approval of the concepts by the TC. 3) Add the Extension mechanisms to Common Types and get formal approval from the TC. 4) Publish "How To" / "Best Practices" documentation 5) From here on any standard can use Extensions:   5.1) For new standards, the work done for TEP or DE can serve for guidance.   5.2) To allow for the use Extensions in the spirit of "layers" ("Community Extensions") in existing standards, a "small" addition to the schema is required - an Errata could be sufficient to accomplish this.   5.3) To allow for the full set of extension capabilities (i.e. "list augmentation", "list replacement" and "list reassignment") in existing standards, more substantial changes are needed in the schemas. As our work with TEP has shown, migrating from WD03 (without Extensions) to WD04 (with extensions), such changes can lead to significant simplifications with repercussions in the schema and the specification. In most cases these will be substantial changes that can not be accomplished with a simple Errata. Cheers, Werner From: emergency@lists.oasis-open.org [emergency@lists.oasis-open.org] on behalf of Rex Brooks [rex.brooks@ncoic.org] Sent: Wednesday, April 10, 2013 1:32 PM To: emergency@lists.oasis-open.org Subject: Re: [emergency] Thoughts on EDXL-DE and SitRep Okay, I'll give it some more thought, but I'm  not happy about waiting. Cheers, Rex On 4/10/2013 12:11 PM, Wilkins, Brian M wrote: Extensions should be part of common types so it would be available to any standard using common types.  However, it is still up to any individual standard to allow extensions or not. If they are not part of the schema for the standard, then they are not part of the standard and any adopter trying to add them to a given standard will break interoperability. This in itself explicitly states whether or not Extensions are part of a standard.  If this change is implemented as being suggested, this will not be a minor change to the schema, satisfied by an Errata.  This will remove the choice elements and add a whole new element in possibly many places in addition to adding potentially multiple sets of enumerations.  Someone that implements DE2 as it is today will have to make significant changes to their code base to implement DE X with extensions, or SitRep for that matter.  As both an implementer and a standards member, I think it is in the best interest of our communities to wait, make the changes, and help limit that pain/cost of implementation. IMHO.   V/R, Brian     From: emergency@lists.oasis-open.org [ mailto:emergency@lists.oasis-open.org ] On Behalf Of Rex Brooks Sent: Wednesday, April 10, 2013 2:55 PM To: emergency@lists.oasis-open.org Subject: Re: [emergency] Thoughts on EDXL-DE and SitRep   There is an old saying that if it isn't forbidden, it's mandatory. That is a deliberately extreme notion, but, to be honest, I don't think we need to expicitly state that extension can apply to SitRep and DE, or HAVE and RM for that matter. If we make the change to the edxl-ct, edxl-gsf or edxl-ciq it applies and all we really need to do is to provide some guidance. I absolutely oppose pulling back on SitRep-v1.0 or DE-v2.0. I could have been equivocal, but where's the fun in that? ;-) Cheers, Rex On 4/10/2013 11:18 AM, Elysa Jones wrote: Friends,   We have worked hard getting SitRep1 and DE2 ready for an organizational vote and we currently have a ballot open for the purpose of approving these works as a Committee Specification.  If this passes, the next steps are obtaining statements of use then agreeing (again by special majority) to begin the 60-day review prior to organizational wide balloting.    Discussion over the past several months regarding a “standard” extension method for all of our specifications has been ongoing.  These discussion are best documented in the RIM-SC.  TC members have been made aware of this discussion and invited to participate and stay in touch as it could affect all of our work.  I’ll not repeat any of that discussion here but ask you to keep it in mind as you make your decision about SitRep1 and DE2.   You may recall there were two versions of the DE2 being worked – one with the layer-extension concept and one without.  We decided to go forward without at this time but all agreed we should keep it in mind and find some way to incorporate later - perhaps through common types.  Some of our members are concerned with releasing DE (as well as SitRep) without this extension concept and then trying to make a change later would be problematic.  We all know how long changes can take and we are anxious to get this work out.  We learned in the last couple of weeks that this extension method would solve some issues with TEP as well.  So, after considering putting this in TEP, it has re-opened the discussion about DE and SitRep in some circles.   The bottom line here is that we have members that are re-thinking whether we need to put either of these standards out without this extension concept.  We have sufficient votes today to move the as they are to Committee Specification.  The ballot closes tomorrow.  If we wish to add “extensions” to DE2 and SitRep, we will have to make not only changes to the document and back through public review again.   Personally, having a “standardized” extension method across all our standards is very appealing to me.  However, delaying SitRep and DE2 concerns me if it is going to take another year.  If it can be completed in 6 months, it concerns me a little less - but only if sufficient resources are available to turn this around quickly.  Basically DE2 has already been done and there is a WD version with it included.  I’m not sure about how much time it would take to add it to SitRep.   Please respond to this note with your thoughts.   Regards,   Elysa Jones, Chair   -- 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

Thanks Werner, Did you, perhaps mean TEP1.0 and HAVE2.0? Cheers, Rex On 4/10/2013 2:04 PM, Joerg, Werner wrote: Ok, maybe I can put some order into all this: 1) Let's move the new candidate standards with updated schema and adjusted specification (DE 2.0, TEP 1.0) proceed through the approval process; 2) Validate the Extension mechanisms and get approval of the concepts by the TC. 3) Add the Extension mechanisms to Common Types and get formal approval from the TC. 4) Publish How To / Best Practices documentation 5) From here on any standard can use Extensions:   5.1) For new standards, the work done for TEP or DE can serve for guidance.   5.2) To allow for the use Extensions in the spirit of layers ( Community Extensions ) in existing standards, a small addition to the schema is required - an Errata could be sufficient to accomplish this.   5.3) To allow for the full set of extension capabilities (i.e. list augmentation , list replacement and list reassignment ) in existing standards, more substantial changes are needed in the schemas. As our work with TEP has shown, migrating from WD03 (without Extensions) to WD04 (with extensions), such changes can lead to significant simplifications with repercussions in the schema and the specification. In most cases these will be substantial changes that can not be accomplished with a simple Errata. Cheers, Werner From: emergency@lists.oasis-open.org [ emergency@lists.oasis-open.org ] on behalf of Rex Brooks [ rex.brooks@ncoic.org ] Sent: Wednesday, April 10, 2013 1:32 PM To: emergency@lists.oasis-open.org Subject: Re: [emergency] Thoughts on EDXL-DE and SitRep Okay, I'll give it some more thought, but I'm  not happy about waiting. Cheers, Rex On 4/10/2013 12:11 PM, Wilkins, Brian M wrote: Extensions should be part of common types so it would be available to any standard using common types.  However, it is still up to any individual standard to allow extensions or not. If they are not part of the schema for the standard, then they are not part of the standard and any adopter trying to add them to a given standard will break interoperability. This in itself explicitly states whether or not Extensions are part of a standard.  If this change is implemented as being suggested, this will not be a minor change to the schema, satisfied by an Errata.  This will remove the choice elements and add a whole new element in possibly many places in addition to adding potentially multiple sets of enumerations.  Someone that implements DE2 as it is today will have to make significant changes to their code base to implement DE X with extensions, or SitRep for that matter.  As both an implementer and a standards member, I think it is in the best interest of our communities to wait, make the changes, and help limit that pain/cost of implementation. IMHO.   V/R, Brian     From: emergency@lists.oasis-open.org [ mailto:emergency@lists.oasis-open.org ] On Behalf Of Rex Brooks Sent: Wednesday, April 10, 2013 2:55 PM To: emergency@lists.oasis-open.org Subject: Re: [emergency] Thoughts on EDXL-DE and SitRep   There is an old saying that if it isn't forbidden, it's mandatory. That is a deliberately extreme notion, but, to be honest, I don't think we need to expicitly state that extension can apply to SitRep and DE, or HAVE and RM for that matter. If we make the change to the edxl-ct, edxl-gsf or edxl-ciq it applies and all we really need to do is to provide some guidance. I absolutely oppose pulling back on SitRep-v1.0 or DE-v2.0. I could have been equivocal, but where's the fun in that? ;-) Cheers, Rex On 4/10/2013 11:18 AM, Elysa Jones wrote: Friends,   We have worked hard getting SitRep1 and DE2 ready for an organizational vote and we currently have a ballot open for the purpose of approving these works as a Committee Specification.  If this passes, the next steps are obtaining statements of use then agreeing (again by special majority) to begin the 60-day review prior to organizational wide balloting.    Discussion over the past several months regarding a “standard” extension method for all of our specifications has been ongoing.  These discussion are best documented in the RIM-SC.  TC members have been made aware of this discussion and invited to participate and stay in touch as it could affect all of our work.  I’ll not repeat any of that discussion here but ask you to keep it in mind as you make your decision about SitRep1 and DE2.   You may recall there were two versions of the DE2 being worked – one with the layer-extension concept and one without.  We decided to go forward without at this time but all agreed we should keep it in mind and find some way to incorporate later - perhaps through common types.  Some of our members are concerned with releasing DE (as well as SitRep) without this extension concept and then trying to make a change later would be problematic.  We all know how long changes can take and we are anxious to get this work out.  We learned in the last couple of weeks that this extension method would solve some issues with TEP as well.  So, after considering putting this in TEP, it has re-opened the discussion about DE and SitRep in some circles.   The bottom line here is that we have members that are re-thinking whether we need to put either of these standards out without this extension concept.  We have sufficient votes today to move the as they are to Committee Specification.  The ballot closes tomorrow.  If we wish to add “extensions” to DE2 and SitRep, we will have to make not only changes to the document and back through public review again.   Personally, having a “standardized” extension method across all our standards is very appealing to me.  However, delaying SitRep and DE2 concerns me if it is going to take another year.  If it can be completed in 6 months, it concerns me a little less - but only if sufficient resources are available to turn this around quickly.  Basically DE2 has already been done and there is a WD version with it included.  I’m not sure about how much time it would take to add it to SitRep.   Please respond to this note with your thoughts.   Regards,   Elysa Jones, Chair   -- 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 -- Rex Brooks GeoAddress: 1361-A Addison Berkeley, CA 94702 Phone: 510-898-0670

Here are my thoughts: We can't go back and change the DE 2.0 or SitRep 1.0 schemas later.   Even if we put whatever revised list data structure in the 'common types', that won't change what is used in the DE 2.0 / SitRep 1.0 specification.  Just because we update common types does not inherently update common types across other standards. Any revision to the choice element that I used to create 'default' value-lists would require a major revision, an errata wouldn't cover it. I don't think / want this to take a long time.  I think we just need to work out: What is the future of the value-list (and related list structures) across EDXL How do we handle default list values How do we need to change the schemas for DE 2 / SitRep 1 to support the above. After we have that discussion we can make the changes and move on.  From there we can provide guidance on how to use these concepts going ahead. Make sense? I spoke with Elysa about this today and I'm willing to put some folks behind making this happen in a timely way.  If we can pick a single time to meet weekly, I think we can have this hashed out without too much hassle. Thanks, Don McGarry Lead Software Systems Engineer The MITRE Corp. dmcgarry@mitre.org (703) 595-9375 @dpmcgarry From: Rex Brooks < rex.brooks@ncoic.org > Reply-To: Rex Brooks < rex.brooks@ncoic.org > Date: Wednesday, April 10, 2013 5:28 PM To: " emergency@lists.oasis-open.org " < emergency@lists.oasis-open.org > Subject: Re: [emergency] Thoughts on EDXL-DE and SitRep Thanks Werner, Did you, perhaps mean TEP1.0 and HAVE2.0? Cheers, Rex On 4/10/2013 2:04 PM, Joerg, Werner wrote: Ok, maybe I can put some order into all this: 1) Let's move the new candidate standards with updated schema and adjusted specification (DE 2.0, TEP 1.0) proceed through the approval process; 2) Validate the "Extension" mechanisms and get approval of the concepts by the TC. 3) Add the Extension mechanisms to Common Types and get formal approval from the TC. 4) Publish "How To" / "Best Practices" documentation 5) From here on any standard can use Extensions:   5.1) For new standards, the work done for TEP or DE can serve for guidance.   5.2) To allow for the use Extensions in the spirit of "layers" ("Community Extensions") in existing standards, a "small" addition to the schema is required - an Errata could be sufficient to accomplish this.   5.3) To allow for the full set of extension capabilities (i.e. "list augmentation", "list replacement" and "list reassignment") in existing standards, more substantial changes are needed in the schemas. As our work with TEP has shown, migrating from WD03 (without Extensions) to WD04 (with extensions), such changes can lead to significant simplifications with repercussions in the schema and the specification. In most cases these will be substantial changes that can not be accomplished with a simple Errata. Cheers, Werner From: emergency@lists.oasis-open.org [ emergency@lists.oasis-open.org ] on behalf of Rex Brooks [ rex.brooks@ncoic.org ] Sent: Wednesday, April 10, 2013 1:32 PM To: emergency@lists.oasis-open.org Subject: Re: [emergency] Thoughts on EDXL-DE and SitRep Okay, I'll give it some more thought, but I'm  not happy about waiting. Cheers, Rex On 4/10/2013 12:11 PM, Wilkins, Brian M wrote: Extensions should be part of common types so it would be available to any standard using common types.  However, it is still up to any individual standard to allow extensions or not. If they are not part of the schema for the standard, then they are not part of the standard and any adopter trying to add them to a given standard will break interoperability. This in itself explicitly states whether or not Extensions are part of a standard.  If this change is implemented as being suggested, this will not be a minor change to the schema, satisfied by an Errata.  This will remove the choice elements and add a whole new element in possibly many places in addition to adding potentially multiple sets of enumerations.  Someone that implements DE2 as it is today will have to make significant changes to their code base to implement DE X with extensions, or SitRep for that matter.  As both an implementer and a standards member, I think it is in the best interest of our communities to wait, make the changes, and help limit that pain/cost of implementation. IMHO.   V/R, Brian     From: emergency@lists.oasis-open.org [ mailto:emergency@lists.oasis-open.org ] On Behalf Of Rex Brooks Sent: Wednesday, April 10, 2013 2:55 PM To: emergency@lists.oasis-open.org Subject: Re: [emergency] Thoughts on EDXL-DE and SitRep   There is an old saying that if it isn't forbidden, it's mandatory. That is a deliberately extreme notion, but, to be honest, I don't think we need to expicitly state that extension can apply to SitRep and DE, or HAVE and RM for that matter. If we make the change to the edxl-ct, edxl-gsf or edxl-ciq it applies and all we really need to do is to provide some guidance. I absolutely oppose pulling back on SitRep-v1.0 or DE-v2.0. I could have been equivocal, but where's the fun in that? ;-) Cheers, Rex On 4/10/2013 11:18 AM, Elysa Jones wrote: Friends,   We have worked hard getting SitRep1 and DE2 ready for an organizational vote and we currently have a ballot open for the purpose of approving these works as a Committee Specification.  If this passes, the next steps are obtaining statements of use then agreeing (again by special majority) to begin the 60-day review prior to organizational wide balloting.    Discussion over the past several months regarding a “standard” extension method for all of our specifications has been ongoing.  These discussion are best documented in the RIM-SC.  TC members have been made aware of this discussion and invited to participate and stay in touch as it could affect all of our work.  I’ll not repeat any of that discussion here but ask you to keep it in mind as you make your decision about SitRep1 and DE2.   You may recall there were two versions of the DE2 being worked – one with the layer-extension concept and one without.  We decided to go forward without at this time but all agreed we should keep it in mind and find some way to incorporate later - perhaps through common types.  Some of our members are concerned with releasing DE (as well as SitRep) without this extension concept and then trying to make a change later would be problematic.  We all know how long changes can take and we are anxious to get this work out.  We learned in the last couple of weeks that this extension method would solve some issues with TEP as well.  So, after considering putting this in TEP, it has re-opened the discussion about DE and SitRep in some circles.   The bottom line here is that we have members that are re-thinking whether we need to put either of these standards out without this extension concept.  We have sufficient votes today to move the as they are to Committee Specification.  The ballot closes tomorrow.  If we wish to add “extensions” to DE2 and SitRep, we will have to make not only changes to the document and back through public review again.   Personally, having a “standardized” extension method across all our standards is very appealing to me.  However, delaying SitRep and DE2 concerns me if it is going to take another year.  If it can be completed in 6 months, it concerns me a little less - but only if sufficient resources are available to turn this around quickly.  Basically DE2 has already been done and there is a WD version with it included.  I’m not sure about how much time it would take to add it to SitRep.   Please respond to this note with your thoughts.   Regards,   Elysa Jones, Chair   -- 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 -- Rex Brooks GeoAddress: 1361-A Addison Berkeley, CA 94702 Phone: 510-898-0670

I will go along with whatever the group wants and do what needs to be done. Just one note: It is seldom our intentions that hold us up, (though that does happen and I admit my share) but our schedules and other things that are beyond our control. So, let's rock and roll. Cheers, Rex On 4/10/2013 6:23 PM, McGarry, Donald P. wrote: Here are my thoughts: We can't go back and change the DE 2.0 or SitRep 1.0 schemas later.   Even if we put whatever revised list data structure in the 'common types', that won't change what is used in the DE 2.0 / SitRep 1.0 specification.  Just because we update common types does not inherently update common types across other standards. Any revision to the choice element that I used to create 'default' value-lists would require a major revision, an errata wouldn't cover it. I don't think / want this to take a long time.  I think we just need to work out: What is the future of the value-list (and related list structures) across EDXL How do we handle default list values How do we need to change the schemas for DE 2 / SitRep 1 to support the above. After we have that discussion we can make the changes and move on.  From there we can provide guidance on how to use these concepts going ahead. Make sense? I spoke with Elysa about this today and I'm willing to put some folks behind making this happen in a timely way.  If we can pick a single time to meet weekly, I think we can have this hashed out without too much hassle. Thanks, Don McGarry Lead Software Systems Engineer The MITRE Corp. dmcgarry@mitre.org (703) 595-9375 @dpmcgarry From: Rex Brooks < rex.brooks@ncoic.org > Reply-To: Rex Brooks < rex.brooks@ncoic.org > Date: Wednesday, April 10, 2013 5:28 PM To: emergency@lists.oasis-open.org < emergency@lists.oasis-open.org > Subject: Re: [emergency] Thoughts on EDXL-DE and SitRep Thanks Werner, Did you, perhaps mean TEP1.0 and HAVE2.0? Cheers, Rex On 4/10/2013 2:04 PM, Joerg, Werner wrote: Ok, maybe I can put some order into all this: 1) Let's move the new candidate standards with updated schema and adjusted specification (DE 2.0, TEP 1.0) proceed through the approval process; 2) Validate the Extension mechanisms and get approval of the concepts by the TC. 3) Add the Extension mechanisms to Common Types and get formal approval from the TC. 4) Publish How To / Best Practices documentation 5) From here on any standard can use Extensions:   5.1) For new standards, the work done for TEP or DE can serve for guidance.   5.2) To allow for the use Extensions in the spirit of layers ( Community Extensions ) in existing standards, a small addition to the schema is required - an Errata could be sufficient to accomplish this.   5.3) To allow for the full set of extension capabilities (i.e. list augmentation , list replacement and list reassignment ) in existing standards, more substantial changes are needed in the schemas. As our work with TEP has shown, migrating from WD03 (without Extensions) to WD04 (with extensions), such changes can lead to significant simplifications with repercussions in the schema and the specification. In most cases these will be substantial changes that can not be accomplished with a simple Errata. Cheers, Werner From: emergency@lists.oasis-open.org [ emergency@lists.oasis-open.org ] on behalf of Rex Brooks [ rex.brooks@ncoic.org ] Sent: Wednesday, April 10, 2013 1:32 PM To: emergency@lists.oasis-open.org Subject: Re: [emergency] Thoughts on EDXL-DE and SitRep Okay, I'll give it some more thought, but I'm  not happy about waiting. Cheers, Rex On 4/10/2013 12:11 PM, Wilkins, Brian M wrote: Extensions should be part of common types so it would be available to any standard using common types.  However, it is still up to any individual standard to allow extensions or not. If they are not part of the schema for the standard, then they are not part of the standard and any adopter trying to add them to a given standard will break interoperability. This in itself explicitly states whether or not Extensions are part of a standard.  If this change is implemented as being suggested, this will not be a minor change to the schema, satisfied by an Errata.  This will remove the choice elements and add a whole new element in possibly many places in addition to adding potentially multiple sets of enumerations.  Someone that implements DE2 as it is today will have to make significant changes to their code base to implement DE X with extensions, or SitRep for that matter.  As both an implementer and a standards member, I think it is in the best interest of our communities to wait, make the changes, and help limit that pain/cost of implementation. IMHO.   V/R, Brian     From: emergency@lists.oasis-open.org [ mailto:emergency@lists.oasis-open.org ] On Behalf Of Rex Brooks Sent: Wednesday, April 10, 2013 2:55 PM To: emergency@lists.oasis-open.org Subject: Re: [emergency] Thoughts on EDXL-DE and SitRep   There is an old saying that if it isn't forbidden, it's mandatory. That is a deliberately extreme notion, but, to be honest, I don't think we need to expicitly state that extension can apply to SitRep and DE, or HAVE and RM for that matter. If we make the change to the edxl-ct, edxl-gsf or edxl-ciq it applies and all we really need to do is to provide some guidance. I absolutely oppose pulling back on SitRep-v1.0 or DE-v2.0. I could have been equivocal, but where's the fun in that? ;-) Cheers, Rex On 4/10/2013 11:18 AM, Elysa Jones wrote: Friends,   We have worked hard getting SitRep1 and DE2 ready for an organizational vote and we currently have a ballot open for the purpose of approving these works as a Committee Specification.  If this passes, the next steps are obtaining statements of use then agreeing (again by special majority) to begin the 60-day review prior to organizational wide balloting.    Discussion over the past several months regarding a “standard” extension method for all of our specifications has been ongoing.  These discussion are best documented in the RIM-SC.  TC members have been made aware of this discussion and invited to participate and stay in touch as it could affect all of our work.  I’ll not repeat any of that discussion here but ask you to keep it in mind as you make your decision about SitRep1 and DE2.   You may recall there were two versions of the DE2 being worked – one with the layer-extension concept and one without.  We decided to go forward without at this time but all agreed we should keep it in mind and find some way to incorporate later - perhaps through common types.  Some of our members are concerned with releasing DE (as well as SitRep) without this extension concept and then trying to make a change later would be problematic.  We all know how long changes can take and we are anxious to get this work out.  We learned in the last couple of weeks that this extension method would solve some issues with TEP as well.  So, after considering putting this in TEP, it has re-opened the discussion about DE and SitRep in some circles.   The bottom line here is that we have members that are re-thinking whether we need to put either of these standards out without this extension concept.  We have sufficient votes today to move the as they are to Committee Specification.  The ballot closes tomorrow.  If we wish to add “extensions” to DE2 and SitRep, we will have to make not only changes to the document and back through public review again.   Personally, having a “standardized” extension method across all our standards is very appealing to me.  However, delaying SitRep and DE2 concerns me if it is going to take another year.  If it can be completed in 6 months, it concerns me a little less - but only if sufficient resources are available to turn this around quickly.  Basically DE2 has already been done and there is a WD version with it included.  I’m not sure about how much time it would take to add it to SitRep.   Please respond to this note with your thoughts.   Regards,   Elysa Jones, Chair   -- 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 -- 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