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] EDXL HAVE and NIEM 2.1 dictionary alignment?


Over time a great deal of disinformation and misinterpreted information has led people astray.  Bottom line is following the process you outline and creating these artifacts for HAVE will create an IEPD that is non-compliant and not interoperable with the OASIS standard.  If some of these artifacts are needed for valid reasons (analysis etc.) and CAM can help, fine.  However, people take info like this and run with it under false pretenses.  We’ve seen it many times.  The OASIS standards are not perfect and we’ll all work on that, but in the meantime the OASIS standard is the standard and NIEM is not for those specific functional exchange areas supporting emergency and disaster response and management. 

 

The governance and process being worked for the EM domain between S&T and FEMA with OASIS is attempting to help bridge NIEM and EDXL, such that EDXL becomes NIEM compliant.  The adaptor pointing to the EDXL standard facilitates this, and maintenance of an EM data dictionary may assist both EDXL and the building of other IEPD’s.  However the results of the process below results in NIEM IEPD’s that are not  EDXL compliant (at least at this juncture).  Those federal and state implementers and NIEM management need to understand this.

Thanks,

Tim Grapes

Evotec

"When your work speaks for itself, don't interrupt"

- Henry J. Kaiser

 

From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Tuesday, July 14, 2009 10:28 PM
To: Gary Ham
Cc: emergency@lists.oasis-open.org; 'Timothy Grapes'; 'Lee Tincher'
Subject: RE: [emergency] EDXL HAVE and NIEM 2.1 dictionary alignment?

 

Gary,

 

Oh boy - this got wildly overly complex!!!

 

Can we have a time out please?!?

 

The wantlist.xml is a simple construct used by the online NIEM SSGT.  It is REQUIRED as part of an IEPD submission for those folks who know and need IEPDs.  They are an absolutely SOB to create manually online - but having CAM create one of these for you in 30 seconds by pushing a button - is likely to make adults breakdown, laugh and cry.  Feels like cheating.

 

Once you have a Wantlist.xml done for you its easy to then delete and tweak as desired.  Hence the supplied base EDXL HAVE wantlist.xml uploaded earlier.  That's probably saving people days of work manually.

 

Now the magic is - once you have the wantlist.xml - you can have the NIEM SSGT create a subset schema for you.  Of course in the context of OASIS EDXL this is irrelevant - because you are not using it.  However 

developers of NIEM exchange schemas - normally need it.

 

Again - we're back to what is formally required for a valid IEPD.  A wantlist.xml, and crossreference schema, an exchange schema and a XML example instance, and you're business rules documentation.

 

So the good news is we can create all of these for EDXL HAVE - and that is really important for federal and state implementors who will need these things for their project documentation to justify what they are doing.

 

Simple - nothing more than that.

 

Thanks, DW

 

p.s. If you want to try out the SSGT with the wantlist.xml - go to this link - click on the top right "Options" - and then upload it.

 

 

 

 

 

 

 

Thanks, DW

-------- Original Message --------
Subject: RE: [emergency] EDXL HAVE and NIEM 2.1 dictionary alignment?
From: "Gary Ham" <hamgva@cox.net>
Date: Tue, July 14, 2009 6:14 pm
To: "'Lee Tincher'" <ltincher@evotecinc.com>, "'David RR Webber (XML)'"
<david@drrw.info>
Cc: <emergency@lists.oasis-open.org>, "'Timothy Grapes'"
<tgrapes@evotecinc.com>


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!

 

 

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?

 

Gary,

 

Good thoughts.

 

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.

 

Enjoy, DW

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


Folks,

 

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.

 

 

Gary A. Ham

http://grandpaham.com

703-899-6241

Grandpa can do IT!

 


 

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]