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

["Kon Wilms" <kon.wilms@ndsamericas.com>]

>> 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.

>> 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.

>> 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.

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?

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.
***********************************************************************************