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?



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.



Gary A. Ham



Grandpa can do IT!


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.


Thanks, DW

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






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