RE: [emergency] HAVE draft comment posted

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

Hi Rex,

  I'm in Germany - just arrived this morning - and am afraid I will be sound
asleep by the time the meeting happens.

  I'll make your day :-) After an initial 60-day public review, the TC may make
non-substantive (i.e. editorial) changes without requiring further review. If
the TC makes substantive changes (and the TC decides whether or not such changes
are substantive) than they must submit for a minimum 15-day public review. The
additional burden is that the new public review draft must contain a complete
change log, and preferably, a change-marked version, since only those changes
made since the previous review are subject to comment.

  In general, I agree that this is a large issue - Elysa may want to speak with
Jon Bosak (UBL chair) about the OASIS UBL NDR v1.0, although I think Sylvia has
spoken well of the challenges. 

Regards,

Mary

> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Thursday, November 02, 2006 8:38 PM
> To: mary.mcrae@oasis-open.org; 'Rex Brooks'; 'Lee Tincher'; 
> 'Tim Grapes'; 'Elysa Jones'; emergency@lists.oasis-open.org
> Subject: RE: [emergency] HAVE draft comment posted
> 
> Hi Mary,
> 
> I am happy to be corrected here, but it was my understanding 
> that a substantive change required a second full public 
> review. I'm fairly sure that this would more than qualify for 
> a substantive change since it would in some cases literally 
> change the name of elements and attributes. I agree that it 
> would be unfair to ask people to spend time reviewing, and, 
> presumably, testing when we think a major change is likely. 
> The problem, in my opinion, is that we are not going to be 
> able to do the due diligence in this case in a week or two, 
> or even just a month, when I look at the amount of time other 
> committees and work groups have put in on the issues in NDR, 
> when what we have is fit to use now. If I could in good 
> conscience give my blessing to NIEM, it would be fine, but I 
> need a lot more information and time to study it before I can 
> say that, and I think, in the end, we would have to opt for a 
> more international standard.
> 
> You could join the conversation at 4:45 p.m. this afternoon 
> if you'd like to weigh in. We were hoping to only spend 15 
> minutes on it and approve moving forward with HAVE but I 
> think it is now unlikely that we wil be able to do that.
> 
> Cheers,
> Rex
> 
> At 8:08 PM +0100 11/2/06, Mary McRae wrote:
> >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
> 
> 
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309