Re: [emergency] HAVE draft comment posted

[Rex Brooks <rexb@starbourne.com>]

Hi Tim,

I posed my initial response earlier, but I wanted 
to specifically address where in the process this 
should be taken up wrt HAVE.

My own feeling (subjective) is that it should be 
held back until a subsequent version, e.g. v1.1. 
or 2.0 because I suspect it will meet the 
criterion that a substantive change requiring a 
new 60-day public review has a threshold or 
trigger whereby a substantive change is one that 
"breaks" existing applications.

Objectively, we literally can't afford to hold 
this up, or vendors will produce their own 
menagerie of proprietary solutions. This is what 
happened for the OASIS SOA Reference Model TC 
(and current Reference Architecture SC). It has 
endured and continues to face the proliferation 
of ESBs and "SOA Fabrics"  jockeying for the 
inside track in the marketplace while we 
carefully crafted the Reference Model and 
continue to work on the Reference Architecture. 
However, because both the model and architecture 
are largely abstract, much like we can make the 
NDR we can, I believe, absorb ESBs and Fabrics, 
albeit with a very flexible shoe horn.

So while the comparison is not precise, the 
effect that ESB vendors have been running away 
with the marketplace still applies.

So we will have to attempt to incorporate NDR, 
crafting it as a non-breaking, non normative 
"best practice" in an appendix during and 
immediately after the 60-day review IF we have 
the time--which is to say, IF we are not swamped 
with industry comments. We will also need to 
include the advice that we expect to incorporate 
a general-purpose NDR methodology in the next 
version of HAVE and EDXL_DE along with all 
subsequent members of the EDXL family.

We may be able to do this because what we are 
doing is establishing a methodology for NDR, not 
a controlled vocabulary in itself. If NIEM is 
looking for a the greater restriction of its own 
controlled vocabulary, which is what we feared 
early on in Mike Daconta's initial statements, we 
would have a greater challenge, and I would have 
to take the position that we are required to 
ensure international applicability over any 
specific national systems.

Either way, its a tough pill that it is better to 
take now than postpone because it is not going to 
taste any better, and likely to ferment into much 
worse, if we wait.

Cheers,
Rex

At 2:57 PM -0500 11/1/06, Tim Grapes wrote:
>All,
>
>I and others on and off the OASIS EM-TC would 
>like to post a recommendation that the National 
>Information Exchange Model (NIEM) Naming and 
>Design Rules (NDR) be adopted and applied to the 
>HAVE committee draft.  My understanding is that, 
>although a consistent convention was used to 
>name the elements, no formal NDR has been 
>followed for HAVE or for Resource Messaging (RM).
>
>Please note that not adopting the NDR does not 
>prevent use of NIEM to develop exchanges using 
>EDXL standards; however, the difficulty for 
>practitioners may be increased otherwise.  I 
>realize that this feels Federal 
>government-driven, but I don't see a down-side 
>since the particular semantics applied should 
>not negatively impact the International 
>community.
>
>Benefits:
>·         Use HAVE as the starting point to 
>begin applying a published and consistent naming 
>convention across the EDXL standards
>·         Promote reuse and facilitate simpler 
>and more seamless use of NIEM for the 
>development of IEPD's and implementation of 
>exchanges using the EDXL standards.
>·         Provide a straight-forward avenue and 
>mechanism for state and local organizations to 
>comply with grants language which specifies NIEM 
>and EDXL
>
>We do not feel that the specification should be 
>held up; HAVE should proceed into the 60-day 
>comment period with this and other comments that 
>have been posted.  If adopted by the TC, 
>recommend that the NIEM NDR be adopted for the 
>draft Resource Messaging and subsequent 
>standards, and possibly to the Distribution 
>Element when a successive version is put forth.
>
>I welcome any comments or feedback.  I will be 
>on the call Thursday at 4:45.  Because HAVE is 
>pending committee vote, I don't know where this 
>comment should be formally posted.  Please 
>advise and I will ensure that gets done.
>
>Sincerely,
>Tim Grapes
>Evolution Technologies, Inc.
>Office:  (703) 654-6075
>Mobile:  (703) 304-4829
><mailto:tgrapes@evotecinc.com>tgrapes@evotecinc.com
>
>
>From: Elysa Jones [mailto:ejones@warningsystems.com]
>Sent: Wednesday, November 01, 2006 6:18 AM
>To: emergency@lists.oasis-open.org
>Subject: [emergency] Call for quorum - Thurs 11/2 4:45PM EST
>
>Dear EM-TC Members,
>
>We did not have a quorum for our meeting 
>yesterday and we would like to get the HAVE 
>moved forward to public comment, as well as 
>review/approve the meeting notes for the past 
>few meetings.  We had our meeting which is 
>summarized in the notes that will be uploaded 
>for review but without a quorum, we were not 
>able to do any business.  We will plan to have a 
>short meeting on Thursday just before the 
>Msg/Not meeting on Resource Thursday evening at 
>4:45PM EST.  The EM-TC part of the meeting 
>should only last 15 minutes if everyone can be 
>prepared to vote on HAVE.  If you have any 
>issues on the draft as it is posted or 
>corrections to the meeting notes for the Sept 
>and Oct meetings, please post them to the list 
>as soon as possible.
>
>Thanks!
>Elysa Jones, Chair
>OASIS EM-TC
>Engineering Program Manager
>Warning Systems, Inc.
>
>PS - The EIC meeting will be today Nov 1.  You 
>can dial in to 800-320-4330 pin # 327547
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.1.409 / Virus Database: 268.13.20/508 - Release Date: 10/31/2006
>
>
>--
>No virus found in this outgoing message.
>Checked by AVG Free Edition.
>Version: 7.1.409 / Virus Database: 268.13.22/512 - Release Date: 11/1/2006
>
>
>Attachment converted: Macintosh HD:NIEM_NDR-0.3.pdf (PDF /«IC») (0019F2A1)


--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309