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
> >> >>