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] Re: [emergency-comment] FW: [CAP] Unique Message Identifiers in CAP


On Mar 3, 2004, at 10:39 AM, Rex Brooks wrote:

> In other words, the more of the discussion we can have here, the less 
> we need to discuss in the meeting.

I completely agree with this. Something we have not done very well is 
debate and discuss topics via the list. Yes, we all have day jobs that 
keep us busy, but at the same time it is clear that when we are the 
point of voting, a lot of people either do not fully understand the 
issues, or the people that understand have not fully discussed them. We 
seem to take the "vote on it and move on" rather than "address the 
issue, which may mean a vote" approach, which as Chair concerns me. It 
is a train wreck waiting to happen. That being said, consider this 
nothing more than some stimulation to discuss topics in more detail and 
at greater lengths on the list.

> My own take on these is that they fall within the implementation 
> guide/note, not as part of the spec. Or perhaps, these are candidates 
> for the FAQ. I don't personally think that these are candidates for 
> the the factsheet.

I agree these are not fact sheet items, but I do not agree they are 
implementation guide/note items. This is a normative topic that should 
be discussed in the spec - at least better than it is today. The spec 
MUST define the hard requirements, and the implementation guide should 
ONLY be there to support how those hard requirements are implemented. 
It should NOT start to define its own requirements (ie: the spec should 
not say to be unique and imp guide tells how to be unique, but rather 
the spec should define how to be unique and the imp guide describe how 
to build that uniqueness into an implementation)

> You are correct though, IMHO, that we do have more immediately 
> important issues to wrestle with, including the ICS 201, to which some 
> DHS developments pertain, such as being included in the National 
> Incident Management System, NIMS. I would, in that connection, 
> appreciate any news that can be forwarded or presented to us.

I somewhat disagree with this comment. That specifically we have "more 
immediately important issues." Our most important issue is to ensure 
CAP is done right, is successful, and is adopted by not just government 
projects, but also commercial applications that target all sectors that 
deal with crisis. This is why the TC was started. Trying to take on 
another work, while we are still getting our sea legs with CAP, is a 
huge no-no. They right books about this (read Crossing the Chasm when 
you have a chance).

> I am personally looking at developing a voice-controlled application 
> of that form within a web services context, but it is definitely an 
> overlap issue for WML/HTML, and might very well be combined with 
> closed circuit video or Simultaneously Multimedia Integration 
> Language, SMIL, apps. Of course, it's important to focus on what can 
> be achieved in the short term, in terms of specification work we can 
> add for the simplest technologies first, if our work is even needed in 
> those areas, or what. It's the OR WHAT that concerns me, so I think we 
> should at least start the discussion on IF SC next week as well.

Now this is what I agree with. I too have a million other things I want 
or would rather the group to be working on, but right now we need to 
ensure CAP is best position for success, and as such, while it is great 
to have offline discussions on other topics, we must focus on it.

--
R. Allen Wyke
Chair, OASIS Emergency Management TC
emergency-tc@earthlink.net



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