All,
Up front I want to highlight the quality and thoughtfulness of
the comments provided by Alessandro. The focus now is upon the process,
approach and timing to address this valid input given the process this standard
has already been though and consideration of moving targets. Mary’s
clarification is an important one and we need to focus on the goal. I
believe that the approach being proposed is backwards. My opinion is that
both the schema and data dictionary should be normative and be
consistent. Rather than skirting the actual issues by messing with
definitions of what’s normative and not normative in the
dictionary, we should decide what changes can be incorporated now with minimal
effort, and with no risk of an additional public review. Substantive
changes should not be addressed now, but in a future release 1.1 in conjunction
with the NIEM data dictionary/RIM proposal Lee referred to (see below).
In this context, I need to understand which of the 70 comments specifically may
be addressed now vs. a later release.
So, my input for the immediate issue is this:
- I am not in
favor of incorporating changes at this time that would take much more than
a week of editing and review. My opinion is that the geo issues
could take us well beyond.
- I am not in favor
of incorporating changes that would put the HAVE standard in any risk of
yet another public review beyond the 60-day it is now entering.
- I believe the
entire data dictionary should be normative (this is supported by and
consistent with Dublin Core). However, if compromise is needed
perhaps “Comments” and “Requirements Supported”
could be non-normative, with the rest (element, type, usage, definition)
normative.
- Now, moving
forward I agree with Lee’s input regarding NIEM. A concept /
proposal was presented during the San Diego face to face meetings.
Understanding more needs to be worked out, the TC gave a head-nod in
principle which opened the door to pursue further program alignment
work/agreements between the DM program, NIEM and NIMS. Those agreements
are being finalized and DM has just this week formally asked that the
OASIS EM-TC now engage in defining a plan and process.
- I agree that
Alessandro note does support looking at NIEM as a common data dictionary
/ RIM concept, consumed by EDXL with a closed loop process to maintain
the that dictionary (the NIEM EM domain).
Just my 2-cents.
From: Mary McRae
[mailto:mary.mcrae@oasis-open.org]
Sent: Friday, September 28, 2007 8:56 AM
To: 'Alessandro Triglia'; 'Lee Tincher'
Cc: 'Dwarkanath, Sukumar'; emergency@lists.oasis-open.org
Subject: RE: [emergency] HAVE comments - explicitly identifying the
normative parts in the data dictionary
I’m afraid that you’ve read much more into my note
than was intended.
Here the language from the TC Process:
All schema and XML instances, whether by inclusion or by
reference, including fragments of such, must be well formed. All expressions
must be valid. Each schema and XML instance that is part of the specification
must be delivered in its own separate plain text file.
The intent is that oftentimes
errors occur when cutting/pasting schemas into a document – characters
may be transposed to other symbols, bits lost, etc. It’s also extremely
difficult for an end user to set up their environment if they have to cut/paste
the schema out of a word processing document or worse, a PDF. So the thing that
is actually parsable is the normative version, if there is one. Note that
the DITA TC produces its specification in both DTD and XSD formats – the
DTD version is explicitly declared as normative. The TC can always decide that
a schema isn’t normative, but they can’t decide that the version of
the schema printed in the document is normative and the separate text file is
informational only.
Regards,
Mary
From: Alessandro Triglia
[mailto:sandro@oss.com]
Sent: Thursday, September 27, 2007 10:47 PM
To: 'Lee Tincher'
Cc: 'Dwarkanath, Sukumar'; emergency@lists.oasis-open.org
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:ltincher@evotecinc.com]
Sent: Thursday, September 27, 2007 22:00
To: 'Dwarkanath, Sukumar'; emergency@lists.oasis-open.org
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
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
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.