MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] Re: [emergency-comment] PPW letter re CAP
Carl, Art, Allen, Elliot, et al,
Let me preface this with a note that I started responding to this
yesterday, got busy, and also felt I should let some time go by and
listen to others before returning to this. So I will leave some of my
initial reply, and address a number of issues that have been raised,
without including all of the the now long list of messages in this
very vital thread. I will leave the specific thread to which I was
responding. The others I will refer to in broad terms, so please
excuse me if I get the attribution of a specific comment wrong.
First, we are not offering excuses, we are making a point of
including stakeholders that have not been adequately representing
themselves, by informing them of where we are in the process. Before
Mr. Fulgate's letter on behalf of PPW, I had not heard a specific
suggestion on how to deal with this issue. There may be a way to make
this suggestion work by specifying that the optional mechanism use
Mime Type declarations as part of text versions of binaries, which
may also make it possible to skirt other issues. Another mechanism
would be to have the option include SOAP, and SOAP with attachments,
which may also provide one (but not necessarily to only) solution to
the problem of including photos, video clips, audio clips, etc. I
realize that this will not suit some applications, but remember that
it is optional.
Art, Allen is right, I meant in my first reply, that this
constituency had not been adequately represented by only using PPW
and you, since their concerns are but one of many for you, and you
have had your hands full with getting CAP to this point. You were
right in that I did not express that in a clear way and so it seemed
that I was saying that they were not represented at all. Mea Culpa.
I think Carl's suggestion is good, but it is also incumbent on us to
get in contact with these folks if we can and let them know where we
stand. I personally think that getting something out there for public
review, and then making sure this audience gets the message is the
best way to get them involved. I am not talking about PPW, but the TV
people.
However, having said that, I also feel I should say that we are going
to run smack into the ROYALTIES quagmire with the TV people, and we
could spend the next year arguing about accepting or not accepting
MPEG-4, and get no standard to use where we can actually use one now.
We have the exact same problem with Flash. This is the main problem
with the feature they suggest of adding an optional mechanism for
adding binary content. OASIS IPR policy requires that any IPR claims
by any parties contributing to the specification be made public
before a standard can be considered for an OASIS-wide vote. I don't
think we have a problem with going forward with the Committee
Specification as it now stands, but this is an issue that we can put
at the top of the list of public comments with which the TC would
necessarily have to resolve before going forward to whichever of the
next steps in the TC process we decide to follow after the initial
30-day public comment period. I should also say that we are not, I
believe, required to limit this public comment period to 30 days, nor
that we must immediately move on to a next stage immediately
thereafter.
I doubt anyone is suggesting that perhaps we should put our work on
indefinite hold until someone comes along to offer a completely
acceptable proposal for handling this constituency? I thought the
point of getting CAP out there was to start getting feedback and get
a v1.0 that addresses the needs we have no proven that we are capable
of addressing now. Maybe the imminence of having a standard that does
not address their needs will stimulate them to do something tangible
about it. However, I have been waiting for reliable RF statement out
of MPEG-4 for five years now, and it still hasn't happened though I
have been assured innumerable times that if I just go along and adopt
their standards, it will all work out. I suspect the the governmental
agencies in general will not accept MPEG-4. I doubt the European
Union will accept it. And the Navy has said in the recent past that
it won't accept MPEG-4.
One last thought, The TV folks, not PPW, have to be responsible for
their own bailiwick. We can't do that for them, nor can we be held up
indefinitely due to their situation.
I think we should move forward and combine the suggestions that Carl,
Elliot and I have made for providing a way to include the Broadcast
Media. We will probably have to do some more work on the spec and go
through another 30-day public comment period, but maybe not.
My last thought is for Allen and the notion of breaking an
application. I ran into this problem in another venue in OASIS and
pointed out that applications have the ability to adapt a lot more
easily than does the spec-writing process. Also, as you say, breaking
does not necessarily mean that the whole app collapses, and when we
get to finally defining a test suite we have the task of clearly
deciding what the differences are between compliance and conformance,
with conformance related ONLY to MUST statements. That's a
particularly tricky distinction. To accommodate this we probably will
need to institute a permanent Conformance SC, but that is a different
matter. In any event, the app builders are represented pretty well,
and you are doing a responsible job of representing their interests
and yours.
I think I have covered most of the comments that I felt were
potential deal-breakers. We are very close to a good and, more
importantly, A VERY USEABLE SPEC. We can improve, indeed we are
already tasked with improving it, but please, let's move forward.
Ciao,
Rex
At 2:59 PM -0600 10/8/03, Carl Reed wrote:
>Art -
>
>We run into these issues all the time in our specification process at the
>OGC. It is impossible to satisfy every requirement for every application in
>every industry. There is an interesting balance between getting a spec out
>for use and getting one out that is also useful! I think the old 80/20 rule
>applies.
>
>Anyway, perhaps a more positive way to position the CAP spec is to say that
>this is version 1 (one) and that future (new) requirements and change
>proposals will be considered and incorporated. This is the way we deal with
>the enhancement issue at the OGC. We accept change proposals, instantiate a
>spec Revision Working Group, work the suggested changes, and then put the
>modified spec up for member vote and adoption. Some of our specs have
>already gone through 5 or 6 revisions in 2 years. This does raise an issue
>of backwards compatibility and deprecation. But how is this different from
>any vibrant piece of technologies life cycle management?
>
>Cheers
>
>Carl
>
>