MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] EM TC 08-26-03 Meeting Minutes
Title: Re: [emergency] EM TC 08-26-03 Meeting
Minutes
My comments and answers are placed after item referred to.
At 10:43 PM -0400 8/28/03, Allen Wyke wrote:
Couple of questions/comments, and I
apologize for not being on the call.
Also, forgive my use of id attributes in my <snip> instances - I
could
not restrain myself :)
<snip id="1">
Continued discussions on symbology for emergency management.
* When talk about symbology not talking
about the artwork, color
and content.
* Are referring to transport,
communicate and interoperate.
Does the TC agree with that
approach? Yes
</snip>
Why not? Why should this not include the artwork? Especially if it
can
be represented in SVG, preserving (if this was the concern) the
XML
nature of the effort. Personally, I think including the artwork, even
if
marked optional in the schema, is something we should do. Not
saying
this is something we must do - just that I am not clear as to why
we
would not want to do this.
I believe what was meant was that we are not as concerned
about the process of choosing or selecting the specific symbols to
represent features like hospitals, police and fire stations, etc,
as we are about ensuring the interoperability of the processes and
features the symbols represent. That doesn't mean that we are not
planning to use the symbols, just that we should not be reinventing
our own symbols, and we should refrain from commenting about the
symbols except through a liaison, if we have one, to the FGDC.
<snip id="2">
Department of Homeland Security has taken the TC letter on board.
</snip>
What "letter"? Didn't see anything else in the minutes
describing such.
The letter suggesting the proper, well-formed and correct xml
coding for the threat advisory levels.
<snip id="3">
There are other project using CAP as well.
</snip>
The MSG SC should attempt to gather a list of these and provide on
their
Website. This could certainly be useful to help show how adoption
is
going.
<snip id="4">
Feedback Process
Rex can we get ideas from OASIS and see how it should
work.
Of course. I simply explained the process used in the two TCs in
which I have participated during this public comment period stage of
the process.
* In other
groups someone took responsibility to review comments
and post to TC list
(numbered and dated) and scheduled TC to
discuss at next TC call.
Anyone who replied to that issue. That
response rely would be
contained in the thread. Good was to
maintain continuity
* During course of discussion make
decision as to whether to
change spec or not
* Not responsible for responding back
to individual.
Art so we use public comment list and TC list to list questions.
One
person puts in order and gives identity and then discussed at TC
level.
Art will take responsibility for reviewing the comments.
</snip>
I think this process is perfect, and is also what I am accustomed to
in
other efforts.
Allen
--
R. Allen Wyke
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency
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.
Tel: 510-849-2309
Fax: By Request
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]