Re: [emergency] Implementing CAP

["Carl Reed" <creed@opengis.org>]

All -

Having read this thread in its entity (My Goodness!), I would like to offer
some advice based on my 5 years experience facilitating the standards
development process at the OpenGIS Consortium.

1. We (OGC) have learned that NO specification/standard is complete and
without "warts" at Version 1. However, we have also learned that it is
vitally important to get a standard out for use in the "real world". If a
spec solves a real world domain problem - but all problems - that is fine.
Which leads to point two.
2. Dialogues such as this one point out why every standards organization has
a revision process for its specifications. We all recognize that an initial
version of a spec - and most likely many succeeding versions - will not meet
all the requirements in the marketplace. This is normal. Nor should a spec
meet all the market requirements for which it is intended. This leads to
undo complexity.
3. So, let's use the OASIS process. Get CAP to version 1.0 so the market
feels that there is a (relatively) stable spec to implement against. Let's
use the OASIS revision process (Change proposals, discussion, edit, revote)
to get to version 1.1 or whatever.
4. And while Robert's rules might say that a Chair is to facilitate only and
not offer opinions . . . At the OGC, an Working Group Chair has the right to
express their opinion as one of the group. Its only fair, especially as many
of our Chairs have extensive knowledge that is really valuable to the
evolution of the process and our standards. The caveat is that they must not
drive a personal or organization agenda. This is counter to an Open
Consensus process. That is why at the OGC, OGC staff monitors all Working
Groups - primarily as a facilitation arbitrator when process issues do
arise.

Finally, I am the Chair for the entire OGC spec process. I can categorically
say that in that role, I do occasionally let the members know what my
opinions are :-)

So, let's move forward, get CAP approved, and move it into the formal
revision process.

Cheers

Carl
OGC

----- Original Message ----- 
From: "R. Allen Wyke" <emergency-tc@earthlink.net>
To: "Kon Wilms" <kon.wilms@ndsamericas.com>
Cc: "Emergency TC" <emergency@lists.oasis-open.org>
Sent: Saturday, March 27, 2004 5:35 PM
Subject: [emergency] Implementing CAP


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