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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]