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.