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.
