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

From
<>
Date
2004-04-01T19:55:26+00:00
ID
Thread
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)" <>

04/01/2004 01:40 PM

        

        To:        "'R. Allen Wyke'" <>

        cc:        

        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

-----Original Message-----

From: R. Allen Wyke [mailto:]

Sent: Thursday, April 01, 2004 1:33 PM

To: Bullard, Claude L (Len)

Cc: 

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

Ok, so are you agreeing or disagreeing with what I proposed? It sounds 

like you agree that we should not attempt to define an XSD (schema) for 

ICS 201, but then you mention preparing a process spec and not address 

the front end (GUI), which is what I *think* we can do with XForms. Or 

are you saying that even touching this with a 10 foot pole (ie: XForms 

too) is way to close?

Just wanting to make sure I am not misunderstanding. Personally, I 

could go either way. I just know that I have a comfort issue with the 

XSD. Jury is out on the XForms idea - it was just a thought that I felt 

was better than defining an XSD.

On Apr 1, 2004, at 2:25 PM, Bullard, Claude L (Len) wrote:

> I agree with Rick.  Don't open liaisons or set dependencies

> on other specifications and standards unless absolutely necessary,

> meaning, your specification can't be used without them.

>

> 1.  Your specification will be tied to the evolution of the

>     other specification, and

>

> 2.  It might lose.

>

> len

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.