Lee is correct, but did not fully explain
the reasoning in my mind. The NIEM NDR recognizes that differences in context
are inevitable, and even valuable. These differences in context are
encapsulated in different name spaces and even different standards
organizations. This encapsulation is very important because it facilitates maintenance
and change as standards are updated and improved (or even abandoned for better alternatives).
Enforced integration introduces rigidity and mutual dependencies to the point
that brittle structures are created that destroy growth and innovation. The
point is that we need to recognize each other, and make use of each others
capabilities through mapping and combined (aggregated) exchange schemas, but
not try to combine incompatible reference schemas. The combined reference
schema is a path that has been tried over and over again in one form or another,
always with eventual failure. The NIEM federated approach (using adapters) is
a breath of fresh air, because it allows encapsulation to work.
So, if you are indeed trying to create a
wantlist from a defined context to be inserted in the NIEM context, you are
essentially following the same road as a programmer who does a code cut-and-paste
from one code module to another and then faces the difficult task of maintaining
the same logic in both modules. It is a daunting task, particularly because NIEM
naming rules WILL require you to modify the items in your wantlist to some
extent. So now you will have to maintain two almost the same, but slightly
different structures, in two different maintenance schedules (NIEM and OASIS)
and try to keep them consistent. OUCH!
So, lets use NIEM’s excellent
encapsulation concepts and only reuse data structures that are exactly the same
in meaning AND structure. According to the NIEM coursework and the NIEM Naming
and Design Rules, what I am advocating is indeed the proper NIEM way, which is
why I support NIEM.
Respectfully,
Gary A. Ham
http://grandpaham.com
703-899-6241
Grandpa can do IT!
From: Lee Tincher
[mailto:ltincher@evotecinc.com]
Sent: Tuesday, July 14, 2009 5:19
PM
To: 'David RR Webber (XML)'; 'Gary
Ham'
Cc:
emergency@lists.oasis-open.org; 'Timothy Grapes'
Subject: RE: [emergency] EDXL HAVE
and NIEM 2.1 dictionary alignment?
Actually – Gary is supporting the
stance I have been trying to get across – we do not need a wantlist – We
created a HAVE adapter and submitted it to NIEM. That approach supports
federation of namespaces…re-creating HAVE from a wantlist does not, it promotes
integration, which will not work as the standards would not be able to exchange
between each other….
Thanks,
Lee
"I
was wondering why that Frisbee was getting bigger - then it hit me."
From: David RR Webber (XML)
[mailto:david@drrw.info]
Sent: Tuesday, July 14, 2009 4:53
PM
To: Gary Ham
Cc:
emergency@lists.oasis-open.org; 'Lee Tincher'; 'Timothy Grapes'
Subject: RE: [emergency] EDXL HAVE
and NIEM 2.1 dictionary alignment?
Attached is a revised
wantlist.xml for EDXL HAVE / NIEM
I found on closer
inspection that there were things the earlier iteration from the weekend
missed.
Plus I've attached a
copy of the EDXL-dictionary.xml - for all domains used.
You can drag and drop
that into Excel and it opens as a spreadsheet - and then filter on namespace
add desired.
--------
Original Message --------
Subject: RE: [emergency] EDXL HAVE and NIEM 2.1 dictionary alignment?
From: "Gary Ham" <hamgva@cox.net>
Date: Tue, July 14, 2009 4:19 pm
To: "'David RR Webber (XML)'" <david@drrw.info>, "'Timothy
Grapes'"
<tgrapes@evotecinc.com>
Cc: <emergency@lists.oasis-open.org>, "'Lee Tincher'"
<ltincher@evotecinc.com>
This thread happened to coincide with a
rather detailed study of NIEM that I have been doing recently. In fact, I
just posted to my blog http://grandpaham.com a
comment on what I like most about NIEM and a warning not to force like concepts
from differing contexts into the same structure. I am going to repeat the blog
post here (although if I wanted to drive traffic I would make you go to my
site):
I have been studying the National Information Exchange Model (NIEM)
fairly extensively over the last few weeks. I have even read the NIEM Naming
and Design Rules document from beginning to end. I will admit that I went into
it with something of a jaundiced view. As a veteran contributor to the
DoD data model and an outside observer of the GJXDM (recently), and a large
scale IBM model (a long time ago), I have real reservations about the usability
and maintainability of any all-knowing, all-seeing model. I have, at
least at this point, become a believer in NIEM. Why? Because
NIEM accepts the notion that a federation between separately name-spaced models
makes sense, both within NIEM, and with external standards defined outside the
heavy NIEM NDR discipline (or defined with a different heavy discipline).
The notion of defining an Adapter for NIEM use of other standards is a
brilliant concept. This, combined with the Information Exchange Package
Documentation (IEPD) methodology for documenting the contextual use of data
used in exchanges has made me a fan.
The problem with this “federation of
standards” concept is that it makes tools (and “auto-magic” validation) harder
to build. As a result there is a tendency to try and force all of the
standards back into the all-knowing, all-seeing model. It is a seductive idea,
but not a good idea. Let’s look at a very simple example: EDXL Resource
Management uses the Customer Information Quality (CIQ standard) for Person
Names. This allows internationalization for all kinds of different Naming
structures and for a wide variety of Addressing schemes. NIEM (as a
national model) is much more U.S.
centric, particularly in the use of PersonName tag. Both CIQ and NIEM are
appropriate in their respective namespaces (and the NIEM NDR respects this fact
by allowing for the adapter wrapper for external standards). If we
try to combine the two standards by defining CIQ elements as NIEM elements
directly in order to make the subschema generator work more easily, we blur
important distinctions that were developed for good reason.
So, we need to use NIEM IEPD methods. They
are excellent. But we must resist the desire to force single definitions for
concepts that may appear to be the same, but actually differ due to the context
in which they were defined. In other words, do not force a merger of
conceptual domains, unless they actually are the same. NIEM lets us
federate in the building of an IEPD. We should take advantage of
that capability.