OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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