[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] HAVE comments - explicitly identifying the normative parts in the data dictionary
|
Well – I’ve been debating this
response for hours….looks like we should go with the short-term solution
as described – but I feel it is necessary to point out that if we were to
begin using a standardized data dictionary in the future this would not be a
problem. NIEM is based on the Dublin-Core metadata descriptions (which
specify normative definitions) and it has a well defined set of Naming and
Design Rules (NDR). Why do we need to continually re-invent the
wheel? The definitions described below do not meet accepted metadata
definitions (again Dublin-Core) and we are running the risk of looking
disjointed between our own EDXL standards. Lets adopt a over-arching data
dictionary for all of our future efforts and put the “normative/non-normative”
arguments to rest. Thanks, Lee 'We the unwilling, led
by the unknowing have been doing the difficult with little for so long that we
are now ready to tackle the impossible with nothing.' -- Local Fire
communications reserve volunteer motto From: Dwarkanath,
Sukumar [mailto:Sukumar_Dwarkanath@sra.com] All, We reviewed all of Alessandro’s comments (it was a
grueling 3.5 hr session), and many comments could be attributed to an
underlying theme - lack of information in the data dictionary that explicitly identified
the normative parts. As a resolution, many of the comments can be addressed by
the following items: -
Separating the comments row into
two rows: Constraints (which will include normative language) and Comments
(non-normative), and -
Including a few sentences at the
beginning of the data dictionary that identifies that the data dictionary is
non-normative, except for the following: ‘Element’,
‘Usage’ and the new ‘Constraints’ row. The schema would
be identified as normative, which I think was an implicit understanding. So, my suggestion is to include the above given that: -
it is directly relevant to
compliance -
it would not take too much effort
to create the above pieces since, following the new compliance requirements
from OASIS, I had earlier identified the normative pieces in the HAVE
specification. If we decide on Tuesday, I can have an updated version by the
end of the week. -
it addresses most comments I wanted to run it by the TC to get view and thoughts from
others Most of the other comments are editorial and can be
incorporated quite easily. It definitely provides clarity. I feel a few of them
should be deferred to the next release. I will post the document with the
suggested disposition soon. Thanks Sukumar ------------------------------------------------------ Sukumar
Dwarkanath Touchstone SRA
International 1920 N
Street NW sukumar.dwarkanath@touchstone.com 202-449-7761
(direct) 703-629-4074
(mobile) 202-338-6106
(fax) This electronic message transmission contains information from SRA International,
Inc., which may be confidential, privileged or proprietary. The information is
intended for the use of the individual or entity named above. If you are not
the intended recipient, be aware that any disclosure, copying, distribution, or
use of the contents of this information is strictly prohibited. If you have
received this electronic information in error, please notify SRA immediately by
telephone at 866-584-2143. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]