Implementing CAP

[R. Allen Wyke <emergency-tc@earthlink.net>]

Changed the subject of this message to more accurately reflect the  
discussion, which started at:

http://lists.oasis-open.org/archives/emergency/200403/msg00042.html

On Mar 26, 2004, at 5:33 PM, Kon Wilms wrote:

>> I do not disagree at all with this statement. I just feel like we are
>> at Square 1/2 - not 1. There are certainly roads I have been down
>> before that didn't pan out that are not reflected in 1.0, which is why
>> it doesn't surprise me we are seeing some of the comments we are on
>> both our list and the CAP list.
>
> On the point of 'almost there but not quite' I would be interested to  
> hear
> from other people who have implemented CAP and the CAP schema. We had  
> to do
> some modifications to get it to work on strongly-typed parsers,

Stop the press (just for a sec). Would love to hear what modifications  
you had to do. Good feedback to the group for the next version.

> and right
> now we are sitting with two extra schemas for two platform  
> implementations.
> In that sense, 1.5/2 is true.

Submit these schemas, if you do not mind, as well. Can do a comparison  
with the 1.0 schema.

> However due to the fact that we have a stable
> transport which is flexible enough to accomodate any filetype,  
> transporting
> CAP has been a literal no-brainer.

Ahhh, but that is the point. You already have a transport - or at least  
one you have standardized on internally. In terms of CAP, do you  
require people to do it your way, or hit the highway?

>> Do you have over 1,000 possible systems that generate alerts (or
>> consume depending on the role of your system)? Basically, do you have
>> over 1,000 connectors that you have to build? I am using the word
>> "limit" in terms of whether or not you have a finite number of
>> potential connectors you have to build.
>
> With a subscriber base worldwide of more than 20 million smartcards  
> spanning
> two to three dozen platforms, yes, even 0.5% of that for CAP deployment
> would be > 1000. But the fact that you have 1000 systems doesn't mean  
> you
> have 1000 different implementations.

Not disagreeing with your logic, but the example I am giving is 1000  
different systems that do require different implementations. My concern  
is that they can (ie: CAP provides no guidance). Some do it one way for  
performance reasons, others do it because of internal guidelines, and  
yet others do it simply because they like green instead of yellow. I am  
not at all proposing we lock CAP down to 1 way or the highway - I am  
only saying we should provide guidance on how to transport, so we can  
at least ensure some level of interoperability in shipping these alerts  
around.

Lets be honest - people's lives could be at stake here. I know our  
software is in that kind of position. Last thing any of us wants to  
happen is for a CAP message to not get where it was going, because it  
was using some obscure transport, or worse yet, it got there but "how"  
it was implemented made the rendering/receiving application  
misinterpret the data.

> Its also impossible that it will ever
> be down to the wire of one single protocol and transport.

I do not disagree there. I think it will take several at a minimum.

> Connectors will
> always be required when working with different arms of the government  
> or
> private sector.

Hmmmm, I think that while that is the most likely case, I think it is  
because of the network it is being shipped across, rather than because  
of gov vs. private.

>> Its not because every page's use of the <img> tag is different. It is
>> due to the number of standards it supports - not the number of
>> variations of the standards it supports. I use to work for a company
>> that had a formal relationship with Netscape, and they use to embed  
>> our
>> code.
>
> Would that be <img src=blah.gif> <img src = "blah.gif"> <img  
> src=blah.gif/>.
> Its the lexical parsing nightmare within the DOM that adds to the  
> bloat,
> more than any variation/combination of DOM parsers.

Oh now, come on - you know good and well they use 1 function that  
normalizes all the data combinations before it is handled by the  
rendering engine :)

> And Netscape always was
> one of the most bloated ;-). But thats just my humble opinion.

Fair enough :)

> Cheers
> Kon
>
>
> *********************************************************************** 
> ************
> Information contained in this email message is intended only for use  
> of the individual or entity named above. If the reader of this message  
> is not the intended recipient, or the employee or agent responsible to  
> deliver it to the intended recipient, you are hereby notified that any  
> dissemination, distribution or copying of this communication is  
> strictly prohibited. If you have received this communication in error,  
> please immediately notify the postmaster@nds.com and destroy the  
> original message.
> *********************************************************************** 
> ************
>
> To unsubscribe from this mailing list (and be removed from the roster  
> of the OASIS TC), go to  
> http://www.oasis-open.org/apps/org/workgroup/emergency/members/ 
> leave_workgroup.php.
>
>
-------------------
R. Allen Wyke
allenwyke@earthlink.net
Fax: 214.722.1529