[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]