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.

Cheers,
Rex

However,

At 1:06 PM -0500 11/10/08, Ponikvar, Donald <CTR> wrote:
>Rex-
>
>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
>discussion.
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>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
>problems)
>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
>standard. 
>
>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.
>
>Steve
>
>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
>
>steven.streetman@associates.dhs.gov
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>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-----
>From:
>emergency-return-1131-Donald.Ponikvar=associates.dhs.gov@lists.oasis-ope
>n.org
>[mailto:emergency-return-1131-Donald.Ponikvar=associates.dhs.gov@lists.o
>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
>clarification).
>
>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"/>.
>
>Cheers,
>Rex
>
>>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%
>>
>>Hi,
>>	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,
>>
>>--
>>jake@jpw.biz
>>--
>>
>>
>>
>
>
>--
>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]