Re: [emergency] PPW letter re CAP

[Eliot Christian <echristi@usgs.gov>]

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.

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.

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.

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

Eliot