Re: [emergency] Re: [emergency-comment] RE: Content ( was RE: [emergency-comment] RE: [CAP] RE: CAP-list digest...)

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

On Mar 24, 2004, at 1:50 PM, Kon Wilms wrote:

>>> Couldn't it be argued that an implementation has to at least do 'some
>>> work'?
>> There is plenty of work the implementation has to do - no doubt about
>> that. But much like an accountant that has to follow the IRS rules,
>> these rules should make a valiant effort to remove ambiguous areas.
>> That allows implementers to not start at square 1, but rather start
>> where you can get into the real down and dirty details of implementing
>> a standard.
>
> Square 1 is always a known baseline. Most times the 'real' starting  
> point is
> either undefined, unattainable, or a pipe dream. For initial adoption  
> of a
> standard, work almost always begins at square 1.

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.

>>> A standard isn't defined by its ability to transparently cross all
>>> protocol,
>>> interface, and transport boundaries. Thats shooting too high, and any
>>> such
>>> attempt to tie all these aspects together is doomed to failure.
>> I do not disagree with that statement at all, nor does anything I have
>> said convey such a statement. A standard is, however, defined by its
>> level and scope of adoption, which has a direct correlation with the
>> clarity in which it approaches it target implementer/market.
>
> A new standard needs early adopters to carve the initial niche areas of
> transport, protocol, interface, and aggregation to get it rolling. It  
> can't
> just roll out and work flawlessly. At some point someone has to blaze  
> the
> trail -- others will learn from their experience.

Again, I do not disagree at all. At the same time, as we are the group  
putting out the work, we must walk a fine like of giving enough for  
people to use, but not too much to stymie innovation.   We need to  
point people in the right direction just enough, so they are not  
running around implementing things a million different ways.

>>> I see no problem with having to implement connectors. Its just part  
>>> of
>>> the
>>> natural cycle of interfacing to external systems.
>> That is because your world of possibilities is limited. You would not
>> say that if you had to interface with 1000 systems. Just the overhead
>> of keeping track of each of the alert suppliers, let alone the
>> programming involved can kill anyone. The reason we have a standard,
>> which is to consolidate these 1000 (and I wish it was only 1000) types
>> of alerts into a single format and method to exchange. Doing so means
>> that any implementation, be it mine, yours, or whoevers, can actually
>> and honestly exchange alerts. It is not unlike how a gazillion Web
>> pages are exchanged and rendered in various browsers. Sure, there are
>> some subtle differences, but its not a bunch of one-offs for each Web
>> page.
>
> Limited how so? Please elaborate.

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.

> If I deploy a CAP service I have to be able to ingest CAP messages,  
> just
> like any other CAP server out there. Maybe there is confusion here  
> about
> moving CAP messages around (and interfacing to  external CAP servers),  
> and
> stuffing existing alerting data into CAP messages? In terms of the  
> latter -
> nothing to be done except write a connector, and wait for the  
> originator to
> adopt CAP (if at all). In terms of moving CAP messages around -
>
> As for one-offs on web pages, it quite literally is. Ever wonder why  
> that
> 'stripped down' Firebird still consumes 10Mb of RAM with no data  
> loaded?

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.

> 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
Chief Technology Officer
awyke@blue292.com
919.806.2440