RE: [emergency] Meeting Minutes: 2004.01.13

[Rex Brooks <rexb@starbourne.com>]

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

-- 

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