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:]
>> Sent: Thursday, November 02, 2006 4:30 PM
>> To: Lee Tincher; 'Rex Brooks'; 'Tim Grapes'; 'Elysa Jones';
>>
>> 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:]
> > >Sent: Thursday, November 02, 2006 8:56 AM
>> >To: Tim Grapes; 'Elysa Jones';
>> >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:>
>> >>
>> >>
>> >>From: Elysa Jones [mailto:]
>> >>Sent: Wednesday, November 01, 2006 6:18 AM
>> >>To:
>> >>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
