[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?
OK, what I think you are saying is that
the wantlist is an artifact of creating the subset schema according to the IEPD
process and only includes already defined NIEM codes, element, and types. ( I
will send separate correspondence to confirm. You may be right. I may be wrong.
If I am wrong, NIEM may want to change the term “wantlist” to “reuselist” as it
make no semantic sense whatsoever in its current name.) I think you are also saying
that you can use
This does not change my level of concern. External standards need to stand on their own. This is why NIEM put the adapter concept in place. That is why the Naming and Design Rules expressly include the use of an adapter for the purpose of encapsulation. Mixing in elements from NIEM should be done only as an imported reference schema in our own namespace that is built from a subset schema in the NIEM space. Otherwise you break encapsulation which will cause maintenance side effects that will gradually grind usability to a halt on both sides.
So what I am saying is this: If there is a mix of elements in HAVE that are made from both NIEM and non-NIEM content, we are in trouble, because we did not segment our schemas appropriately in the first place. We will need to build two separate support schema in our namespace to support the two (or at least pull all of the NIEM compliant subset out of the main schema and reference it from HAVE).
Luckily I do not think that any of the elements in HAVE are consciously NIEM compliant (i.e., the ones that are compliant are so by accident/casual reuse instead of NIEM structured design and therefore require thorough review (for example a CIQ PersonName and a NIEM PersonName represent the same concept but are NOT semantically equivalent). What I am saying is that it is a bad idea to try and mine the current HAVE spec for individual NIEM elements and types, just because you can. Let the HAVE exchange document stand on its own with an adaptor. It is the right way. We can eventually build our RIM to include NIEM subsets (or be NIEM subsets). Our exchanges can reference the RIM, but they need to stand on their own.
So, to be honest, I am not arguing that using CAM to do what you are doing is bad; I am arguing that doing what you are doing is a mistake in and of itself (with or without CAM) for any currently documented external standard exchange. Your methods may, however, be appropriate for other IEPD activities, particularly the definition of new exchange schemas, as long as the new exchange schema is backed with appropriate subset schemas designed to make needed encapsulation possible.
Gary A. Ham
Grandpa can do IT!
From: David RR Webber
No - that is not correct - the wantlist.xml carries the components you are using from the EXISTING dictionary of NIEM collection of "stuff".
See my reply on what goes into an IEPD. The idea is that an exchange designer should maximize reuse of items that are already in NIEM - and then only define domain specific new peices in your XSD that are not currently in NIEM - outside of the wantlist.xml items. This is exactly what we have in EDXL HAVE already - bits that are in the NIEM - and bits that OASIS has defined.
What I've done for CAM is take the NIEM Access database for v2.0 - convert it into an XML format for the dictionary and properties - and then written xslt - that will compare the CAM template of your exchange XSD (in this case EDXL) to that NIEM XML dictionary and build the wantlist.xml for you.
What NIEM teaches is doing this manually online using the SSGT to search and find the matching parts. Needless to say that is a tedious and slow process!
Fortunately the SSGT
includes ability to save and then upload wantlist.xml - so I'm merely
automating this all - so you can simply upload the wantlist.xml that
Hope that is clearer now.