RE: [emergency] HAVE draft comment posted

["Mary McRae" <marypmcrae@gmail.com>]

Hi everyone,

  I just wanted to add a point of clarification. If substantive changes are made
after an initial 60-day public review, the specification must be submitted for
an additional public review that must lest at least 15 days. So, unless the
changes are so extensive that the TC feels it is impossible to identify the
changes and restrict comments to that area, the 2nd review could be for as few
as 15 days.

The bigger question is - if you're planning on making the change, it seems
dishonest to ask people to spend time reviewing when you know it will be changed
rather than waiting.

Regards,

Mary 

> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Thursday, November 02, 2006 4:30 PM
> To: Lee Tincher; 'Rex Brooks'; 'Tim Grapes'; 'Elysa Jones'; 
> emergency@lists.oasis-open.org
> Subject: RE: [emergency] HAVE draft comment posted
> 
> Yes, Lee,
> 
> I understand that, but I suspect it would take less time to 
> do it that way...
> 
> It's a question of one versus two 60-day public review 
> periods. If we have a 60-day pr now, we will need to have 
> another if we add the NDR to HAVE after the pr now. That 
> means it will be at least six to eight months in all 
> probability before HAVE gets approved OASIS-wide. If we do 
> 1.1 in six months or eight months that is not out of line 
> with what we have seen in other circumstances,but tin the 
> meantime we have a functional HAVE. However, I have a 
> suggestion to avoid that, too.
> 
> This is not going to be an easy or rubber stamp effort, I'm afraid. 
> That's why I think the best option is to create an EDXL 
> Reference Information Model (EDXL_RIM) that includes a 
> methodology for NDR with which recast, but backward 
> compatible applications of existing specifications could be 
> built. That way what an implementer does is to create 
> translation table from existing terms and definitions to the 
> RIM NDR, and then just reference the namespace of the 
> translation table in the application. Legacy apps work as is, 
> or get translated. 
> The translation fit sthe NDR and are interoperable with 
> sucessive versions of the specs.
> 
> I prefer that rather than re-engineering the specifications 
> themselves. My reply to Tim was trying to address the 
> immediate problems in a way that fits with what most people 
> are familiar with doing, but my strongest advice is to do the 
> RIM rather than fussing with individual specifications at 
> this time. I believe we are going to end up having to do both 
> anyway, so I'm not especially inclined to argue over it.
> 
> I will however, insist on doing the due diligence to create 
> the specs correctly, regardless, and that means we are going 
> to have the discussion over how to shape the NDR for fitting 
> international as well national needs. THAT's the discussion I 
> would prefer to postpone until a later time, after we decide 
> how we are going to deal with the work in front of us.
> 
> Cheers,
> Rex
> 
> At 9:01 AM -0500 11/2/06, Lee Tincher wrote:
> >Rex,
> >
> >If we waited until the next version to adopt the NDR 
> wouldn't that put 
> >us in the position of having an immediate major release 
> (v2.0) since I 
> >doubt that it would be backwards compatible from the initial release?
> >
> >Thanks,
> >Lee
> >'We the unwilling, led by the unknowing have been doing the 
> difficult 
> >with little for so long that we are now ready to tackle the 
> impossible 
> >with nothing.' -- Local Fire communications reserve volunteer motto
> >
> >-----Original Message-----
> >From: Rex Brooks [mailto:rexb@starbourne.com]
> >Sent: Thursday, November 02, 2006 8:56 AM
> >To: Tim Grapes; 'Elysa Jones'; emergency@lists.oasis-open.org
> >Subject: Re: [emergency] HAVE draft comment posted
> >
> >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
> 
> 
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309