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
Very well stated. While some areas, at the appropriate time, need to be
drilled down into even further than you have most graciously done here,
I agree on all points.
Allen
On Thu, 2003-10-09 at 11:03, Rex Brooks wrote:
> 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
> >
> >