MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] Meeting Minutes: 2004.01.13
Title: RE: [emergency] Meeting Minutes:
2004.01.13
Hi Allen, Everyone,
My responses are inline. In regard to the latter parts of Allen's
message that I am not commenting on now, I will try to get to later
this week.
At 12:06 PM -0500 1/14/04, R. Allen Wyke wrote:
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.
Two points: One--We need the three corporate members to make the
supporting statements, attesting that they are "successfully
using" the specification, for inclusion in the submission for
OASIS approval. Personally, I would prefer to
have these statements made after Art's final, clean CAP v.1.0 is
ready, AND for these statements to be made after using this final ,
clean version; and, Two--I think Allen's comments constitute a
"minority report," and should be officially included as such
in the materials provided to the OASIS Administration as part of the
submission, IF we vote to move the specification forward. (I also
happen to think this is a good thing, beyond being necessary.)
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.
We did not have any great disagreements with your patterns that I
recall, but there were enough questions that we could not answer for
ourselves that we decided to defer accepting the submission. At some
point, and it need not be very far into the future, if these questions
can be answered to the satisfaction of those who had them, (I do not
want to characterize these for any one else, especially since I did
not have those questions though neither did I have the answers.), then
I would have no objection to having the patterns added to an
errata.
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.
If we put it in an errata, we can include it in the
implementation guide. I started to write more but realized that I just
plain don't agree or disagree enough to work at it. I didn't and don't
seriously disagree with the patterns. I know I can work with the spec
either way. I'll leave it at that.
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
To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
Ciao,
Rex
Tel: 510-849-2309
Fax: By Request
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]