David,
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 CAM to read the exchange
schema and extract the NIEM defined components to build the wantlist, which can
then be used to generate the subset schema.
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.
Respectfully,
From: David RR Webber
(XML) [mailto:david@drrw.info]
Sent: Wednesday, July 15, 2009
10:38 AM
To: Gary Ham
Cc:
emergency@lists.oasis-open.org; 'Timothy Grapes'; 'Lee Tincher'
Subject: RE: [emergency] EDXL HAVE
and NIEM 2.1 dictionary alignment?
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 CAM created instead - check that it works OK - and then
you are done - minutes instead of days of work!
Hope that is clearer
now.
-------- Original
Message --------
Subject: RE: [emergency] EDXL HAVE and NIEM 2.1 dictionary alignment?
From: "Gary Ham" <hamgva@cox.net>
Date: Wed, July 15, 2009 7:15 am
To: "'David RR Webber (XML)'" <david@drrw.info>
Cc: <emergency@lists.oasis-open.org>, "'Timothy Grapes'"
<tgrapes@evotecinc.com>, "'Lee Tincher'"
<ltincher@evotecinc.com>
My understanding of the
IEPD process is that a wantlist is required only for brand new elements.
Reuse of an approved external standard does not require a wantlist. In
fact it would be confusing because it would appear that we are submitting
individual HAVE elements for inclusion in the NIEM vice HAVE as a whole. The
wantlist is for LOCAL data structures that have not been standardized and need
to be. We do not have to create a wantlist for the HAVE standard. Just
get it approved as an external standard and define a NIEM adapter.
You may be confused
because the subschema generator uses the same “wantlist” format for storing the
items you need out of NIEM prior to generating the one ore more subset schemas
that you build in order back the specific (separately name spaced) reference
schema that you use for your exchange schema. But, you do not need to
submit a “wantlist” separately for elements that the subschema generator can
build for you. Just for the new stuff. And approved external standards are not
new stuff. In fact, the HAVE schema with its adapter is actually just another
subset schema as far as the IEPD process goes.
The larger question is
alignment of our RIM with NIEM, which is a RIM of its own. We may need to
think about something there, because there could be value in aligning basic
constructs. But my warning is simple: “there be monsters
lurking!!!!” It is not simple at all.