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: [OASIS Issue Tracker] (EMERGENCY-24) Parallel-track CAP 1.3 and 2.0

    [ https://issues.oasis-open.org/browse/EMERGENCY-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48559#comment-48559 ] 

Steve Hakusa commented on EMERGENCY-24:

From https://www.oasis-open.org/apps/org/workgroup/emergency-cap/download.php/53640/Aproved%20CAP%20SC%20Meeting%20Notes%207-14-14.doc
Elysa added that pursuing multiple versions further splits the time members have to dedicate to each effort and would be an inefficient way to use our scarce resources.  If the TC decides to go this way, more members and oversight will be needed for coordination and the shear effort of developing, completing and maintain the specifications.  It is also confusion for adopters and complicates the efforts of ITU coordination that are already difficult.  We may agree very soon that a 2.0 is the only way to go given resolution of the issues that will drive a new version.

From https://www.oasis-open.org/apps/org/workgroup/emergency-cap/download.php/54224/Sep29-2014-meeting-notes.doc
Eliot Christian raised his concerns about prematurely deciding the direction for CAP (1.x versus 2.x) when all of the issues have not yet been reviewed.  A discussion took place regarding when the SC should inform the TC regarding such a decision.  It was agreed that a discussion regarding the SC's processes should take place at an upcoming meeting in order to ensure all SC members understand and agree.

> Parallel-track CAP 1.3 and 2.0
> ------------------------------
>                 Key: EMERGENCY-24
>                 URL: https://issues.oasis-open.org/browse/EMERGENCY-24
>             Project: OASIS Emergency Management TC
>          Issue Type: Improvement
>          Components: CAP 
>            Reporter: Art Botterell
> A decade into the formalization of CAP we now face the legacy dilemma... do we limit development to incremental steps that maintain back-compatibility with earlier versions, or do we risk limiting interoperability in order to leverage fully the experience and lessons learned of the last ten years?  
> Fortunately we don't actually have to choose; we can have both.  At this point I believe CAP adoption is broad and deep enough globally to tolerate and even benefit from a two-track approach.  
> Competition between the old and the new will happen naturally... and inevitably.  The only real question is whether the next-generation alternative comes from within OASIS or from some other source.

This message was sent by Atlassian JIRA

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