MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] PPW letter re CAP
On Thu, 2003-10-09 at 05:03, Eliot Christian wrote:
> At 03:36 PM 10/8/2003 -0700, Art Botterell wrote:
> >We aren't talking about something that needs to cause a delay... this
> >could be resolved very quickly by adding a single optional element to the
> >spec, with requisite caveats and restrictions set forth in its
> >definition. The mechanism involved has already been tested and proven in
> >a number of XML applications, and implementation could even be defined as
> >optional for most implementers (those not contemplating connections via
> >one-way data links).
>
> Art is exactly right here and I also think we have a precedent in
> the EM TC process we've been using.
I am going to single out our application as an example here, although it
would also apply to others. Please help me understand how adding this
will not break my application? Note that "break" does not mean it will
fall over and die, but that the additional infrastructure, what-ifs,
limitations, etc. are not grossly compromised. So, separate the
technical change from the overall impact to an implementor. Don't
confuse these two.
> The CAP standard was silent about how to send a CAP message within
> any particular service. In testing, we found that interoperability
> demanded that we make a specific decision about the use of SOAP
> (the decision was to use message-style rather than RPC-style SOAP).
> If another vendor were to proceed as DMIS did and implement
> SOAP-encoded CAP, the TC would cite that decision in setting them
> straight. In effect, the TC has already standardized at least one
> service--CAP over SOAP.
And taking that further, it means that as a TC we need to formalize
that. No disagreement here, and in fact it was the very essence of the
lengthy argument Rick and I was making back at the mini-f2f, which was
pushed aside to be a basic "format" test.
> To my mind, the television folks are right where DMIS was. Just as
> DMIS made a choice on how to do CAP in their SOAP service, the TV
> folks need to make a choice about how to do CAP in their particular
> service. The EM TC did not leave DMIS hanging; it would not be fair
> to leave the TV folks hanging.
We did not leave DMIS hanging? That seems to imply the TC gave them
something, which it did not. See comments below on what I mean by this
if it is not clear.
> I say the TV folks should demonstrate the interoperability of
> "CAP over TV" and the mechanism documented just as was done for
> "CAP over SOAP".
Bingo! DMIS, through its efforts to implement the spec, took a stab at
implementing it. During that process they learned a lot, further refined
their approach, and worked with others to come to agreement on how best
to send CAP messages over a SOAP service. With that experience behind
us, the TC can not take those valuable comments and lesson's learned and
try to address them in a normative way - probably as an official Note or
maybe another OASIS Standards (something like CAP Over SOAP as you
mention below). So, why is broadcast media not willing to go through
this exercise as well?
> Eliot
>
>
> 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
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]