Great discussion and some good points –
I agree with Lee that we should follow consistent naming and design rules, and the
NIEM NDR is a definitely a good resource. I think we have spoken about this a few
times before and we all agree in principle that we need to focus on the next steps
in pursuing it.
From my perspective, the schema should
be the authoritative artifact for all the XML elements and structure. As I see
it, the data dictionary provides additional clarification, as needed, and provides
a high level overview to non-technical users. The normative parts in the data
dictionary are mainly the business rules and definitions – the reason we include
the usage and other information is to ensure that this information is conveyed
to non-technical users as well – I think this is important as it eases
the burden on practitioners and does not force them to review technical documents.
The proposed suggestion is for the near term,
and is a compromise to respond to Alessandro’s overall comments of
ensuring well defined compliance statements are well defined. It is clear that
none of us are in favor of delaying HAVE at this point – so, we should
decide on moving forward at the earliest.
Thanks
Sukumar
From: Timothy Grapes
[mailto:]
Sent: Friday, September 28, 2007
11:26 AM
To: ;
'Alessandro Triglia'; 'Lee Tincher'
Cc: Dwarkanath,
Sukumar;
Subject: RE: [emergency] HAVE
comments - explicitly identifying the normative parts in the data dictionary
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:
1.
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.
2.
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.
3.
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.
4.
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.
a.
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.
Thanks,
Tim
From: Mary McRae
[mailto:]
Sent: Friday, September 28, 2007
8:56 AM
To: 'Alessandro Triglia'; 'Lee
Tincher'
Cc: 'Dwarkanath,
Sukumar';
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:]
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.
