OASIS Emergency Management TC

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 19:55 
     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
    








    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