OASIS Emergency Management TC

Re: [emergency] Re: [emergency-comment] PPW letter re CAP

  • 1.  Re: [emergency] Re: [emergency-comment] PPW letter re CAP

    Posted 10-09-2003 14:01
     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
    >
    >