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] 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
(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
) 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
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
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
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.


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.

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request

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