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
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,RexAt 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
-----Original Message-----
From: R. Allen Wyke [mailto:emergency-tc@earthlink.net]
Sent: Thursday, April 01, 2004 1:33 PM
To: Bullard, Claude L (Len)
Cc: emergency@lists.oasis-open.org
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.--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.comTel: 510-849-2309Fax: By Request
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]