RE: [emergency] HAVE draft comment posted

[Rex Brooks <rexb@starbourne.com>]

Thanks Sylvia,

I was not aware of the extent of international adoption, though I was 
aware that ISO 11179 and ISO 15000-5 were getting traction. I was 
actually more concerned that we make our specs more compatible with 
business process automation in bpel, wsbpel, ebXML 
registry/repository, and ubl, though all of this needs to work 
together, hence my suggestion of an EDXL_RIM which will make it 
relatively easy to build translation tables to accommodate 
terminology remediation backwards and forwards, and takes the 
immediate time constraint out of play for both HAVE and Resource 
Messaging short term and Situational Awareness longer term.

However, regardless, there is no easy way to accomplish what we need 
to do, there are only choices between difficult and pains taking 
options and whether we end up duplicating efforts for each of the 
specifications we have already done in order to have consistent NDR 
within HAVE and then retrofitting EDXL_DE. As has now been pointed 
out, it is not simply a matter of incorporating NIEM as is without 
significant consequences. Perhaps we can suggest asking a NIEM expert 
to join our next TC meeting, and perhaps an ISO expert as well, not 
that you are not an expert yourself, Sylvia. But it might be best to 
have a non-TC, possibly non-OASIS expert, or at least someone who 
does not have a major vested interest in this TC work. I am certain 
we can craft an EDXL_RIM with an NDR that is both NIEM and ISO 11179 
and 15000-5 compatible, or that can produce translations of existing 
specifications that are compatible.

Cheers,
Rex

At 8:36 AM -0800 11/2/06, Sylvia Webb wrote:
>Hi Rex,
>
>Although I haven't been able to be active in the TC, I continue to try to
>keep up with it's work. This particular topic is one that I cannot keep
>silent on since software that supports ISO 11179 and it's practical
>implementation, ISO 15000-5 are what my company creates software to for and
>where I spend most of my time in the standards arena.
>
>Adding any NDR that supports ISO 11179 will not be a minor task. It isn't
>something that can be done in a few months. Even with specialized tool
>support it will take a dedicated team many hours of pains taking work.
>Specifically adding the NIEM NDR may also produce a national solution
>instead of a international solution.
>
>I believe that there is an approach that will support multiple NDR including
>the NIEM and support the needs of the international community. Essentially,
>it is proceeding with the RIM work that I believe you have already started
>and incorporating ISO 15000-5 which includes support for ISO 11179-4.
>
>Simply adding the NIEM NDR will not achieve support for the wide variety of
>requirements that the OASIS community will need. The NIEM NDR is a schema
>representation of a data model. In order to support the needs of an
>international community, you need a syntax neutral representation of the NDR
>first. ISO 15000-5 is a syntax neutral representation of 11179.
>Additionally, when the GJXDM was in development, many of the data
>requirements were submitted to UN/CEFACT and subsequently to ISO for
>inclusion in the current version of 15000-5. From the syntax neutral
>representation, you can have any number of NDR to meet specific
>requirements. I am working with various US Government agencies on various
>ISO 15000-5 projects.
>
>Whether we like it or not, ISO 15000-5 and 11179 are being specified in
>multiple governments RFPs now in the US, Europe, Australia, New Zealand, and
>Asia. In the past month I have attended meetings in New Delhi and Sydney
>where some of this standards development work is being done by various
>government bodies as well as private industries. Sooner rather than later,
>there will be an interest in using these standards for EM TC messages. When
>to bite the bullet, what approach to use, and how to move forward at the
>same time to prevent a plethora of proprietary vendor and in-house developed
>solutions are the real questions that need to be discussed and answered.
>
>I believe this requires a lot more discussion and consideration of the
>various approaches and results that one approach over another will produce.
>I hope that I can be available to participate in those discussions.
>
>Sylvia Webb
>GEFEG US
>310-370-3410 - Voice
>310-370-5614 - Fax
>www.gefeg.com -  Internet
>
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>Sent: Thursday, November 02, 2006 5: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