RE: [emergency] Meeting Minutes: 2004.01.13

["R. Allen Wyke" <emergency-tc@earthlink.net>]

I actually had some comments/thoughts about the minutes, but wanted to
keep those separate from the official minutes. I changed the order to
focus on next steps, because the other is more commentary as a member of
the TC, and not as Chair. 

>Resolution of these final two items completes the public 
>comment list and CAP 1.0 is considered complete and ratified by the TC.

The next step is to decide if we are going to push CAP 1.0 up the ladder
to be presented as an OASIS Standard
(http://www.oasis-open.org/committees/process.php#standard). We had some
discussions
(http://lists.oasis-open.org/archives/emergency/200311/msg00024.html -
see comments from Rex towards bottom) in the past about holding and
waiting until another version was created, but nothing was ever really
decided. I will create a Ballot in Kavi to allow us to vote and decide,
but wanted to first see if there was any objection by the voting
membership
(http://www.oasis-open.org/committees/membership.php?wg_abbrev=emergency
) to do that now, verses wait until Art circulates the updated (per the
results of our Issues) draft. 

Please let me know by the end of the week if at all possible.

>2. Issue 22 (Future Version): regarding the alignment of the 
>XML Schema to reflect what is stated in Data Dictionary. Group 
>voted to defer until later time and after additional detailed 
>criteria is established.

I must say that I consider it very unfortunately that we have chosen not
to make this particular set of changes. While I, like anyone else in the
group, does not expect all ideas to represent the majority, I am baffled
as to why this one would even be a question at all - especially since we
had already agreed (see Item 3 in
http://lists.oasis-open.org/archives/emergency/200312/msg00059.html)
that it was a good idea to include. The voting should not have been on
whether to do or not, but whether or not the patterns submitted
(http://lists.oasis-open.org/archives/emergency/200401/msg00003.html)
were correct or not. 

Speaking directly to why this was even an issue, which may help anyone
who does not fully understand why it is important, to place the burden
of exception handling on the implementer to enforce the identified rules
(http://lists.oasis-open.org/archives/emergency/200312/msg00048.html)
defined in the Data Dictionary WHEN it was completely possible to have
the XML parser handle these, is nothing short of unnecessary. Address
when "additional detailed criteria is established"? The Data Dictionary
already established this as "criteria" - we were only aligning the
schema to support those declarations. By simply telling a parser to
validate would ensure each instance of these elements occurrences
conformed to the CAP 1.0 standard schema, but now implementers have to
write code to check for this. Of course, the conformance part of that
last sentence dovetails right into yet another issue....

Per another decision on Issue 10 (How do I know when I have a
CAP-supporting application?), the group decided that "compliance with
CAP" was equal to "validates by agreement with CAP schema". So, when you
put these two together not only is there a discrepancy between what is
in fact a compliant CAP message, as in is it a) validates against the
schema per how the TC voted on Issue 10, or b) validates AND conforms to
the Data Dictionary, but the implementer must now write code to make
sure these elements have the proper key=value pair, etc. formatting.
Will they even check the formatting now, because resolution to Issue 10
does not demand such? Guess that depends on how they interpret our
response to Issue 10.

As a side note, I hope that each of you understand my passion toward
these issues is not based on some pie-in-the-sky "what CAP could
technically be" frame of mind, but rather one based on experience of
developing other standards - some successful, and some not - and more
importantly developing commercially available applications to support
standards. It is not simply a question of "can I use CAP to do what I
need" in terms of our responsibility to the industry, but rather, "does
the design of CAP support the ability to exchange alerts in an
interoperable fashion agnostic of implementation, which is ensured
through implemented (in the spec) forethought on 'how' to facilitate
that exchange." Basically, think globally and avoid things that will
cause people to use it in a way inconsistent with how other's use it. 

Allen