OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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

Rex -

Do not have much time right now to respond - will do so later. However, the
recommendation from the GIS SC was *not* to get involved in the
(contentious) issues related to the content definition of the symbology -
including artwork. The assumption is that from an interoperability
perspective, we will take what is provided, say by the FGDC, and determine
the best means (as per my draft use case) to communicate (transport) these
definitions to some device. So, we are definitely talking about separation
of content from presentation :-)



----- Original Message -----
From: Rex Brooks <rexb@starbourne.com>
To: Allen Wyke <emtc@nc.rr.com>
Cc: Cathy Subatch <CSubatch@eteam.com>; Emergency Management TC
Sent: Thursday, August 28, 2003 10:40 PM
Subject: 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
> --
> Rex Brooks
> GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> W3Address: http://www.starbourne.com
> Email: rexb@starbourne.com
> Tel: 510-849-2309
> Fax: By Request

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]