Hi Alessandro,
I don’t see how my suggestion for
future efforts is counter to anything you state below…..
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: Alessandro
Triglia [mailto:]
Sent: Thursday, September 27, 2007
10:47 PM
To: 'Lee Tincher'
Cc: 'Dwarkanath, Sukumar';
Subject: RE: [emergency] HAVE
comments - explicitly identifying the normative parts in the data dictionary
Hi
Lee,
I
don't want to look as though I am coming from another
planet. I understand your concerns and appreciate your comments. I
am also totally open to considering alternative approaches.
The
only question I have is, don't you think that an OASIS standard should be
written in accordance with the OASIS rules, including its requirements on
normative language and conformance language?
Mary
McRae's email indicated that the XML schema provided as a separate schema
file must be normative, and that any part of it included in
the main document must be regarded and marked as
informative. My interpretation is that this should also apply, as
much as possible, to any equivalent provisions in whatever language they
are expressed--XML Schema, plain English, or dictionary entries.
I may
be wrong, and would like to hear OASIS's opinion on this. I do believe
that it is extremely important for a standard to avoid all the risks inherent
in redundant normative statements or insufficient normative statements.
If there is an issue of clarity in a standard (e.g., a technical provision that
may be difficult to understand), that issue can be easily addressed (and should
be addressed) by providing good descriptive text, summaries,
synopses, figures, or other such informative material, accompanied
by explicit references to the authoritative location in the same document
(or in another document, which may be a schema document) containing the
corresponding normative statement.
That
said, I am not asking for any action that may cause a delay in the publication
of EDXL-HAVE or any of our standards, as I understand that there are
important user communities waiting for them. I will be happy
with any resolution of my comments the TC will want to adopt. Still,
I am very interested in making sure that we eventually produce very good
standards, free of redundance, ambiguity, and insufficient specification.
Alessandro
From: Lee
Tincher [mailto:]
Sent: Thursday, September 27, 2007
22:00
To: 'Dwarkanath, Sukumar';
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:]
Sent: Thursday, September 27, 2007
12:43 PM
To:
Subject: [emergency] HAVE comments
- explicitly identifying the normative parts in the data dictionary
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
Washington
DC 20002
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.
