MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Meeting Minutes: 2003.11.18
[Evaluate Liaison Needs]
* Rex has contact at VoiceXML group at W3C.
* He said that he can handle WSRP, Human Markup, and public health.
* Some discussions this morning with Carl Reed (OGC) and Eliot (Gov
side), so those are covered.
* Would be great to get John Aerts involved for public safety and law
enforcement, although his membership is off and on depending on
obligations.
* Appears we do not need to formalize.
* Rex to send out email to list on who, exactly, we have these informal
liaisons with, so we are all on the same page. Completed at the time of
sending the minutes
(http://lists.oasis-open.org/archives/emergency/200311/msg00020.html).
[Meeting Next Week]
* Several people on holiday - group agreed to cancel meeting and
reconnect following week. Will use the list for any discussions during
this time.
[CAP Comments]
8: Allen updates group on where this issue came from
(http://www.incident.com/pipermail/cap-interop/2003-September/000105.html). After further review, the details of this are covered in various other issues, such as #5 and #7, so it was voted to mark as duplicate.
7: IF SC has sent out first draft document to start to cover this type
of thing - looking for comments.
* Gary has done some research into ebXML, which has gone over these
types of issues in detail in their efforts. Comments that there might be
some issues where CAP has some elements that might be best put in the
wrapper (ie: ebXML). Additionally, some of these are down in <info>,
rather than in the header.
* Kon comments that they have metadata that contains this.
* Eliot: not sure it is right that being embedding is the issue, since
the many <info> each has routing issues.
* Gary: maybe there needs to be some kind of aggregated routing info.
* Art: provides some details on how it could be done using the other
elements, so it is possible.
* Rick: comments that this makes the case for an implementors guide. Can
be done, but needs clarification/guidance.
* Carl: mentions that the IETF is working on a privacy standard to allow
rules to be passed with documents. IFSC going to look into this point.
* Group votes to mark Resolved and to address outside of CAP. Eliot
disagrees. Rex comments that a binary is an exception. There is a
dependency (from a resolution standpoint) on issue #9 with this one.
Group decides to hold on marking Resolved, and to put back at Need More
Info until we get proposed language for #9 (see below).
9: Rick: Kon and Art have been working on schema language to support
this. Art goes on to say that they have been batting around specific
language about this. He and Kon to circulate proposed language to group.
Rex: brings up question about a potential need for rewriting part of the
spec. I am going to try to summarize here, rather than capture all
details, but basically it appears there are some "larger" things, such
as the binary attachment issue (#9), that may need to make it into the
spec we submit as an OASIS Standard. This means we would have to retest
and go back through the review process, which would result in something
like a v1.1 that would be submitted.
29: Lot's of discussion around the intension of these edits. Group
wishes not to open up a whole new lot of comments/questions, and at the
same time the discussion on if we move CAP 1.0 toward full OASIS
Standard status or not (versus a revised 1.1) plays in here. Allen will
send example of the edit.
16: Given Gary's persistence to see this included, the group voted to
approve and to formally call this "Gary's Issue" going forward.
30: Art comments that this is technically possible. Various discussion
around it - Allen to propose some language.
--
R. Allen Wyke
Chair, OASIS Emergency Management Technical Committee
http://www.oasis-open.org/committees/emergency
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]