OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

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

Subject: RE: [emergency] EM-Msg: Meeting Tomorrow_Veterans Day? Fwd: Re:CAP comments summary

Thanks Don, Steve,

After Jacob posted this comment, I did mention in the ensuing 
discussion that I recalled some previous discussion about allowing 
extensions from the process of developing CAP 1.0, but I believe I 
only mentioned that our previous discussion had resulted in not 
including <xs:any>. I did not recall the exact reasons.

Now that Steve's points refresh my memory, I recall similar arguments 
being made that it would open the door to too many possible 
problematic extensions. I look forward to discussing this again as we 
address it in our recommendation. I should be clear that our current 
agenda is to simply recommend to the TC whether we think it is 
advisable to start work on a liimited revision of CAP, in a 1.2 
version, or a more thorough CAP 2.0 version.

I agree, personally, that I don't think it is wise for a CAP 1.2, but 
I think it should be on the table for 2.0 when we take on that work. 
I say that not because I think it is likely to make the cut, only 
because I think it is premature to rule it out at this point.



At 1:06 PM -0500 11/10/08, Ponikvar, Donald <CTR> wrote:
>Sorry I didn't send this to you earlier, but we have been inundated here
>with the preparations for transition since the presidential election.
>But when I saw the proposed agenda for tomorrow, I had to forward this
>to you.
>I circulated your recent discussion regarding the use of <xs:any> to
>some of our techno-wizards at DNDO, who are presently incorporating CAP
>1.1 into a series of NIEM IEPDs for the Department of Homeland Security.
>They all feel that the use of xs:any is not an advisable practice.  The
>following text is from Steve Streetman, one of our lead implementers,
>and a Board member on the Emergency Interoperability Consortium. In
>response to my question about the discussion you had with Jacob
>Westfall, he describes much more eloquently than I the issues as we see
>them.  Please feel free to contact Steve directly to continue the
>Don -
>I do have an opinion.  First, NIEM prohibits the use of <xs:any> because
>it allows someone to put anything they want in that place.  The benefit
>is that someone can add their own specific data right inline with the
>standard without being invalid.  There are several downsides:
>1 - a parser now has to deal with a lot of embedded stuff it doesn't
>know is there and be able to ignore it (potential interoperability
>2 - (we saw this in ASP) vendors will duplicate stuff in the standard in
>their own proprietary format rather than using the standard tags and
>then not test the standard tags because they don't use them themselves.
>3 - (we saw this in ASP, too) vendors can put immense amounts of data in
>the xs:any section so that the files get bloated with non-standard data.
>I think 1-3 are sufficient to discourage us from allowing xs:any in a
>By the way, as the discussion below shows, CAP does not allow xs:any.
>So this isn't the way [David] Lamensdorf has gone astray [in their
>implementation of CAP for the LA interoperability demonstration].  He
>has gone astray by:
>1 - flooding CAP bandwidth with non-alarms
>2 - stuffing sensor data where it doesn't belong and where its structure
>cannot be adequately reflected
>3 - inserting into the CAP milieu things that look like alerts but have
>not been validated and, in fact, are not threats.
>If you have a choice just say no to xs:any.
>Steven S. Streetman
>SETA Support to System Architecture Directorate Domestic Nuclear
>Detection Office
>(202) 254-7430
>Mailing Address:
>Steve Streetman/ DNDO SEAD
>Mail Stop:  7100
>Department of Homeland Security
>245 Murray Lane, Bldg 410  
>Washington, D.C.  20528
>Don Ponikvar
>Donald R. Ponikvar, PhD
>SETA Support, Mission Management Directorate
>DHS/Domestic Nuclear Detection Office
>Washington, DC  20528
>voice:  202-254-7530
>fax:  202-254-7751
>Blackberry:  202-368-4922
>-----Original Message-----
>asis-open.org] On Behalf Of Rex Brooks
>Sent: Monday, November 10, 2008 12:51 PM
>To: emergency-msg@lists.oasis-open.org; emergency@lists.oasis-open.org
>Subject: [emergency] EM-Msg: Meeting Tomorrow_Veterans Day? Fwd: Re: CAP
>comments summary
>Hi Everyone,
>Please excuse me for combining several issues into one message, but
>it seems most efficient.
>1. For the EM-Msg SC, Tuesday is Veterans Day. We have a meeting
>scheduled so it is late to be changing schedules, yet I do not want
>to disrespect our veterans.  However, neither do I want to enforce
>our holidays on our internatonal members, so if you wish to observe
>the holiday, please do, and if we do not have a quorum tomorrow,
>we'll cancell the meeting or discuss whatever issues remain but we
>will not be able to vote on a recommendation to the TC. If we fail to
>reach quorum, which I expect, I would like to schedule another
>meeting next Tuesday to conclude our work so that we can make our
>recommendation to the TC at the next TC meeting. In the meantime, I
>would like to discuss the remaining issue (See 3. below) and our
>recommendation on the mailing list.
>2. For the TC, I am forwarding the message from Jacob Westfall with
>includes two attachments, Cap-NextGen-CommentsList_v1.4 and
>CAP-Comments Summary.doc so that you can see the documents on which
>the EM-Msg will base its recommendation. (Note: See 3 for minor
>3. For both the TC and the EM-Msg SC, I uploaded a slightly different
>version of the CAP-NextGen-CommentsList_v1.4 to the EM-Msg Documents
>Repository that has one additional comment. #31: to add extensibility
>using <xs:any##other minOccurs="0"/>.
>>Date: Sun, 9 Nov 2008 16:03:15 -0500
>>From: Jacob Westfall <jake@jpw.biz>
>>To: Rex Brooks <rexb@starbourne.com>
>>Subject: Re: CAP comments summary
>>Organization: JPW
>>X-Nonspam: Statistical 55%
>>	Sorry this comments summary took so long I was swamped last
>>week.  Attached is version 1.4 of the comments list building on 1.3
>>that you posted.  I've put the comments into categories for Best
>>Practice, 1.2 and 2.0  I've also merged the comment 17 subset in as
>>well.  I cleaned up the formatting and values.   Also attached is a
>>1 page summary document.  It also shows the categories and has the
>>comment numbers and brief description for each.  Many comments are
>>duplicates and so an entry may have several comment numbers attached.
>>	Take a look and let me know if I've missed anything or there
>>are other changes.  Thanks,
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-898-0670

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670

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