[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]