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: Meeting Minutes: 2003.04.06

[Item #1: CAP]
Allen mentions discussion with Jamie regarding that there should not be 
any normative changes to the doc. This basically means no changes at 
all except the name and date, NOT referring to internal normative (data 
dictionary, schema, etc.) vs. non-normative (design principles, 
concepts, etc.) info.

Rob states that he doesn't want to pull it back at this point - that it 
could damage the group. Rex agrees. No other comment. Rob proposes a 
future "point release" - basically a CAP 1.NEXT (1.1, 2.0, etc.). Art 
comments that it is probably a 4 - 6 month process to really address 
the issues and bring CAP.NEXT to market. Allen comments that there is 
more than one way to help reduce the severity of the concerns that have 
been raised. This can come in the form of a non-normative errata, 
Implementer's Guide, etc. or any combination thereof.

Art brings up that people should present solutions with their issues. 
Allen comments that not all people who experience issues know enough to 
also define a solution, but that doesn't mean it is not a valid issue. 
No one is saying we can address a phantom issue (ie: an issue no Member 
will "own"). If the submitter does not understand it enough nor does 
anyone else, then it becomes something the TC can not address. Rick as 
some comments also stating that not everyone knows the "answer", but 
someone in the group may. Rex also states this should be "ok" for 
comments w/o solutions (MINUTE TAKER NOTE: the group did not appear to 
be on the same page at this point, but the next statement helps...).

Carl brings up the fact that people will find errors, problems, etc., 
and the way to handle is through errata. Art clarifies that he is 
speaking more of philosophical differences and having a process for 
triaging or even addressing them.

Jamie joins the call at this point, and Carl asks for his guidance on 
this topic...

Jamie discusses (refer back to what Allen said at intro of meeting) how 
the spec/doc is frozen, at least that version, once it is voted on. 
Examples to help illustrate:

1. What if a semi-colon is in the wrong place? OASIS allows an errata 
document, but the standard can not change at all. Basically the TC can 
adopt this errata document.

2. What above major changes? It is up to the committee as to how, by 
vote, to handle each of these items and issues and where/when they 
appear (ie: 1.1, 2.0, across multiple versions, etc.).

Carl just reflects that basically the TC becomes a "revision working 
group" as it pertains to how to address CAP 1.0. Jamie goes on to point 
out that the next step is to determine if we should do an errata 

Allen asks Art if his questions regarding philosophical differences was 
answered, and if not to restart. Art provides the info again to Jamie 
now the he is on the call. Jamie mentions that a member proposes a 
change. If there is a bunch then there should probably be an agreed 
list that the TC debates/discusses and makes a voting decision on. 
Allen mentions that we have a list started (CAP 1.0 Standard Issues 
List.xls), but that it needs to be updated as of the last 2 weeks 

Rob reflects that he is hearing 2 different paths. One is errata, and 
the second is about enhancing for the next version. Points out that it 
is brand new, and as such, there will be a surge in additional 
comments, etc. Likes the idea of an errata sheet to address immediate 
needs/comments. Seeks agreement that there are flaws that should be put 
in an errata document.

Jamie comments that you should be careful to try and not include 
everything in an errata - plan some of the bigger issues for 2.0. 
Basically, for the errata, look for the things that are easy to include 
and agree on, but avoid things that are larger topics that will take 
more time to address.

Suggestion: if there is a major functionality issues you can 
acknowledge, but state it is to be addressed in a future version.

Jamie suggests that we identify owners (Members) to review the issues 
in the CAP List 1.0 Spreadsheet. Allen will update spreadsheet with 
newer issues and email to group regarding the review of this list.

[Item#2: CAP Evangelization]
Rex has already has 3 articles/resources to draw from and some 
opportunities. See his post 
for a more complete summary.

MINUTE TAKER NOTE: Rex, if I missed anything here please send out to 
group, as I am not sure I captured everything that was important..

At the end of the meeting (after Item #4 discussion) Rex asks if we are 
in agreement with what he wrote for the newsletter. Art brings up that 
the press release is 4/14, so there may be synergy to sync it up. Jamie 
recommends to touch base with Carol. Everyone agrees, so Rex will work 
with her on lining these two publications. Allen will provide "Chair" 
quote to Rex for inclusion.

[Item #3: CAP Future]
We talked all around this in Item #1, so it was not discussed any 
further in the meeting.

[Item #4: IF SC Update]
Rick grabbed the documents off the list and they are in Tom's hands 
now. Tom had to drop off, but they will get together today or tomorrow 
and forward out to group.

1. Update CAP Comments spreadsheet and send out to group from review. 
Determine what items should be in errata.

2. Implementer's Guide outline has been drafted 
and as such, we need to take the items from our Public Comment review 
assigned to the Imp Guide and ensure they are covered.

3. Allen to provide quote for Rex's article. He will continue to work 
the media angle.

4. Tom/Rick to circulate IF SC work.

R. Allen Wyke
Chair, OASIS Emergency Management TC

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