Thanks Elysa,
I think a small clarification is in order. For
that reason, and because we might want to add
this to tomorrow's TC Meeting Agenda, I am adding
the TC list to the addresses for this message.
We started the list at the url cited to collect
comments into CAP 1.2 and CAP 2.0 categories as a
way to see what needed to be done next.
Subsequently, we have chosen to push quickly for
CAP 1.2 (underway). We then planned to launch
into a formal, but currently temporally
unconstrained (no fixed end date), Requirements
Gathering process for CAP 2.0 when CAP 1.2 is
announced for its 60-Day Public Review (very
soon). We don't currently have anyone tasked with
maintaining that list.
I should also say that the motion I made many
months ago for a separate CAP SC to undertake
that work still stands. I think it might be
appropriate to modify that motion to specify the
SC as CAP 2.0 specific, but it should certainy be
discussed as to whether it is a single
issue/version, short-lived SC or a permanent SC.
I could argue both sides, but I do think it
should be its own entity.
I think the constituency for CAP 2.0 greatly
exceeds that of the EM-Msg SC and for that SC to
handle both CAP 2.0 and EDXL-SitRep is more than
a single SC can or should handle. And, because I
am already committed to EM-Msg and EDXL-RIM SCs,
as co-chair, I would not be a candidate for that
role in a new SC.
Cheers,
Rex
At 4:50 AM -0500 5/11/09, Elysa Jones wrote:
>Art and others,
>
>Yes there is a list of issues for CAP 2.0 in the
>spreadsheet at
>http://www.oasis-open.org/apps/org/workgroup/emergency-msg/download.php/31699/CAP-NextGen-CommentsList_v1.4.xls
>
>I've copied Rex Brooks, one of the co-chairs for
>the Msg/Not Subcommittee on this in case he
>wants to add any comments about its completeness.
>
>Cheers,
>Elysa
>
>
>At 04:27 AM 5/11/2009, Michael Staudinger wrote:
>
>>many thanks for the info and pls continue to keep us informed!
>>
>>kind regards Michael Staudinger
>>
>>
>>
>>I don't see any reason we couldn't revisit this in CAP 2.0.
>>
>>Just for background... the selection of feet for the altitude
>>elements, even though we used meters elsewhere, was based on feet
>>being used in aviation. And the decision to standardize on a single
>>unit rather than supporting multiple units was made in order to
>>minimize the complexity of CAP processing at the receiver, which we
>>envisioned including some relatively simple embedded devices. So
>>these choices weren't quite as parochial or inconsistent as they may
>>appear... although that's not to claim they were perfect!
>>
>>Elysa, do we have a formal issues list for CAP 2.0 yet?
>>
>>- Art
>>
>>
>>On May 8, 2009, at 5/8/09 6:18 AM, Eliot Christian wrote:
>>
>>> Hi Micheal,
>>>
>>> Sorry for the delay in my response to the problem you raised wrt
>>> meter/feet for the altitude element in CAP.
>>>
>>> I think you need to raise the issue to the OASIS Emergency
>>> Management TC for consideration in the next version of CAP. (For all
>>> I know, this may be already on their list of issues.)
>>>
>>> The contacts I would use to raise it are cc'd here:
>>> Art Botterell