When using NIEM dictionaries, numerous artificial Details types appear such as
scr:AlertDetails and scr:AddressDetails in the default dictionary example.
Although generated code does define these pseudo-types, it seems misleading to
use the NIEM namespace prefix (e.g., "scr") since they are not part of NIEM.
Shouldn't they be in an exchange or extension namespace with a different
prefix? Shouldn't the GUI make it clear what is actually in NIEM vs. what is
an artificial construct?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We can look at an enhancement to the dictionary UI - to bubble help some
specific guidance text for users. This is not really NIEM specific - with any
dictionary object - users can potentially rename the parent node once inserted
into their XML exchange structure.
The intent of these items that end in Details suffix is that users will do
exactly that - because they really need to set the context of their use of the
object within their own exchange. The NIEM schema of course hides this within
the XSD schema type and ref mechanisms.
So - its debatable if using the actual NIEM namespace is clear or not -
certainly all the components contained within the Details parent are - and it
was directly derived from a XSD schema complexType definition within that
namespace.
We are planning a new Dictionary Evaluation Tool - similar to the Template
Evaluation Tool - that will highlight much more aspects of dictionaries. This
naming need is really only the tip of the iceberg - there are all kinds of
conflicts, anomalies and duplicates/omissions within current NIEM and other
domain dictionaries - that hopefully we can guide people around with this
reporting tool. Look for this in the next CAM v2.2 release. And of course we'd
be happy for more suggestions as to things this dictionary evaluator may spot
- the more you can look the more you find!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When using NIEM dictionaries, numerous artificial Details types appear such as
scr:AlertDetails and scr:AddressDetails in the default dictionary example.
Although generated code does define these pseudo-types, it seems misleading to
use the NIEM namespace prefix (e.g., "scr") since they are not part of NIEM.
Shouldn't they be in an exchange or extension namespace with a different
prefix? Shouldn't the GUI make it clear what is actually in NIEM vs. what is
an artificial construct?
We can look at an enhancement to the dictionary UI - to bubble help some
specific guidance text for users. This is not really NIEM specific - with any
dictionary object - users can potentially rename the parent node once inserted
into their XML exchange structure.
The intent of these items that end in Details suffix is that users will do
exactly that - because they really need to set the context of their use of the
object within their own exchange. The NIEM schema of course hides this within
the XSD schema type and ref mechanisms.
So - its debatable if using the actual NIEM namespace is clear or not -
certainly all the components contained within the Details parent are - and it
was directly derived from a XSD schema complexType definition within that
namespace.
We are planning a new Dictionary Evaluation Tool - similar to the Template
Evaluation Tool - that will highlight much more aspects of dictionaries. This
naming need is really only the tip of the iceberg - there are all kinds of
conflicts, anomalies and duplicates/omissions within current NIEM and other
domain dictionaries - that hopefully we can guide people around with this
reporting tool. Look for this in the next CAM v2.2 release. And of course we'd
be happy for more suggestions as to things this dictionary evaluator may spot
- the more you can look the more you find!