OASIS Emergency Management TC

 View Only
Back to discussions
Expand all | Collapse all

RE: [emergency] Groups - ICS-201-draft0.2.xsd uploaded

  • 1.  RE: [emergency] Groups - ICS-201-draft0.2.xsd uploaded

    Posted 04-01-2004 20:31 
     MHonArc v2.5.0b2 -->

















    emergency message
    







    [Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]
    


    







    Subject: RE: [emergency] Groups - ICS-201-draft0.2.xsd uploaded
    








    Uh oh, with all this agreement, can we call ourselves a standards group?
    
-------------------------------------------
    
Rob Torchon
    
Vice President, Engineering
    
offc: (818) 932 0660 x220
    
 fax: (818) 932 0661
    
cell: (805) 551-6232
    



    

    

    

Rex Brooks <rexb@starbourne.com>

    04/01/2004 03:33 PM
    

    		        
            To:        RTorchon@eteam.com, "Bullard, Claude L (Len)" <clbullar@ingr.com>
            cc:        emergency@lists.oasis-open.org, "'R. Allen Wyke'" <emergency-tc@earthlink.net>
            Subject:        RE: [emergency] Groups - ICS-201-draft0.2.xsd uploaded



    Yup, We are definitely having an epidemic of agreement today. Also if you look at NIMS-90, there's a bleep load of forms in there. That's why I said a data dictionary could be all that is really needed, with perhaps a table of equivalencies for organizational charts or roles/responsibilities and rights/permissions..

    Ciao,
    Rex

    At 2:11 PM -0600 4/1/04, RTorchon@eteam.com wrote:
    I don't feel it is the realm of this TC to specify display mechanisms. These forms can be accomplished in a variety of ways on the web( HTML, PDFs, xForm, java, active x, etc). Plus don't rule out any client side applications.
    

    
Also, targeting just one form is really not a solution. ICS consists of a methodology and a medley of forms( and versions of the same form that are vastly different in some cases), some which relate to others and some which stand alone.  Together they make a system.
    

    
We should retrench and make sure we all understand ICS and our approach in general. NIMS is sufficiently vague that the standard has yet to be defined.
    

    
Rob
    


    
-------------------------------------------
    
Rob Torchon
    
Vice President, Engineering
    
offc: (818) 932 0660 x220
    
fax: (818) 932 0661
    
cell: (805) 551-6232
    

    "Bullard, Claude L (Len)" <clbullar@ingr.com>
    04/01/2004 01:40 PM
    
       
    
        To:        "'R. Allen Wyke'" <emergency-tc@earthlink.net>
    
        cc:        emergency@lists.oasis-open.org
    
        Subject:        RE: [emergency] Groups - ICS-201-draft0.2.xsd uploaded


    

    
I am saying don't normatively associate any spec with any other spec
    
unless you have to.  That's all.  Don't let me confuse you because
    
I don't have time to look into ICS.  I was responding to Rick
    
being uncomfortable with specifying XForms.

    
XForms is an explicit application language.  There are alternatives
    
to implementing XForms so you should be uncomfortable with that choice.

    
Is the process specification meant to be executable or
    
only an abstraction of a process that can be implemented
    
differently?  Do you *need* a process specification or is
    
it informative material provided to help other implementors?

    
Dare to do less in cases where doing more forces you to
    
make choices for the implementors that they can better
    
make for themselves.  Do more if the chances are good
    
that without the extra work, the specification can't
    
be implemented interoperably at all.  Be very certain
    
about interoperation:  systems interoperate; data is
    
portable.  So if you spec interoperations normatively
    
you are designing the system, not the data.

    
len


Related Content