All,
Assuming that the DE
standard reflects Rex’s recollection (pasted below), then I will remove the
issue I submitted. I can live with this.
“…I would have sworn we
agreed that EDXL-DE could have multiple contentObjects with one and only
one payload each, and one and only one DistributionType, so that no
contentObjects could be of a type different than the
DistributionType.”
Thanks,
Whoops – somehow I
missed that change along the way. In fact, during the most recent review
(1/16/06) Elysa asked me whether a related issue I submitted was satisfied and I
responded “yes” based on the committee decision to install that business
rule. Thus, this means that the issue I submitted in fact has not been
addressed… In response to this issue, the business rule was added stating
that the DE may contain only one contentObject, to eliminate the related
complexities.
I don’t want another
60-days, but now don’t understand the resolution offered.
Thanks,
Tim
------------------
(Submitted
11/29/05)
ISSUE 1 - Multiple payloads /
distribution types
DE can carry multiple payloads, and
I just now see a change that shows that DistributionType can be one or MANY as
it should be (so that different payloads in the same DE may have different
distrType). E.g. A DE with 2 payloads – one payload may be a
“response” and the other be a “request”. This is a valid requirement, but
then requires a way to associate distibutiontype(s) with different
payloads. There are also other business needs to relate together multiple
payloads within the same distribution.
OPTIONS:
1- Formalize a business rule where
payloads must always have the same DistributionType. Otherwise, separate
messages must be created for each, or
2- How to associate things to
payloads? Perhaps add an element to the DE contentObject segment called
something like "contentID", providing a unique way to identify each payload?
ISSUE 2 – Incident Identifier and
Description 1 or many?
Same issue as above. If the
business rule above is implemented, then multiple payloads within a DE need to
be related to the same incident. Otherwise, need a way to relate Incident
ID’s and Desc’s with each payload (the “contentObject” thought
above?).
-------------------
Actually that business rule got
changed along the way. As it stands now, each DE can have 0 or more Content
Objects, and each Content Object can have 0 or more payloads.
I personally think is should be each
DE can have 1 or more Content Objects, and each Content Object must have exactly
one payload. IMHO
All,
Just to make sure we are clear, the
incidentID and Description are already
included in the ContentObject as
optional. Being optional, an incident may
or may not be related to the
content, and the spec contains a business rule
that each DE may contain only
one content object.
Mark is suggesting addition of an optional
incidentKeyword to classify the
incident, which is not a complicated
request. I think the decision really
comes down to where we draw the
line and get the DE published, and where we
begin considering additional
requests for the next version.
Regards,
Tim Grapes
Evolution
Technologies, Inc.
Disaster Management egov Initiative
Science and
Technology Directorate/OIC
Department of Homeland Security
Office:
(703) 654-6075
Mobile: (703)
304-4829
tgrapes@evotecinc.com
tim.grapes@associates.dhs.gov
-----Original
Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent:
Friday, January 27, 2006 5:04 PM
To: Aymond, Patti;
emergency@lists.oasis-open.org
Subject: Re: [emergency] FW: Suggestion: Add
incidentKeyword to
contentObject
Hi Folks,
However, good a
suggestion it might seem, I'm not
sure the contentObject requires an
incidentID,
since it might not be related to any specific
incident, or it
might refer to several
simultaneous incidents, and figuring this out
is
not going to be a trivial task.
Ciao,
Rex
At 11:37 AM
-0600 1/27/06, Aymond, Patti wrote:
>Forwarding message from Mark
CarlsonŠ
>
>Patti Iles Aymond, PhD
>Senior
Scientist
>Bioterrorism Preparedness & Response
>Innovative
Emergency Management, Inc.
>Managing Risk in a Complex World
>8555
United Plaza Blvd. Suite 100
>Baton Rouge, LA
70809
>(225) 952-8228 (phone)
>(225) 952-8122
(fax)
>
>From: Mark Carlson - Conneva, Inc. [mailto:conneva@gmail.com]
>Sent:
Thursday, January 26, 2006 11:37 AM
>To: Aymond, Patti
>Subject:
Fwd: Suggestion: Add incidentKeyword to
contentObject
>
>Patti,
>
>I tried sending this message
to the group, but
>the list server rejected my message. Could
you
>forward,
please?
>
>Mark
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>=-=-=-=-=-=-=-=-
>
>I'm
quite sure everyone is hoping for no more
>changes to the EDXL-DE schema
at this point.
>However, as I have begun to work with the
>schema in
our resourcing prototype, I have
>observed that while there are incidentID
and
>incidentDescription elements in the
>contentObject, there is no
provision to classify
>the incident using a valueListURN/value
pair.
>
>This would seem to be necessary for consistency.
>In
other words, if it is a good idea to have an
>incidentDescription and
incidentID in the
>contentObject, there should also be an
optional
>incidentKeyword to classify the
incident.
>
>Regards,
>
>Mark Carlson
>
>IEM
CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE:
><http://www.ieminc.com/e_mail_confidentiality_notice.html>http://www.ieminc
.com/e_mail_confidentiality_notice.html
--
Rex
Brooks
President, CEO
Starbourne Communications Design
GeoAddress:
1361-A Addison
Berkeley, CA 94702
Tel:
510-849-2309
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
No
virus found in this incoming message.
Checked by AVG Free
Edition.
Version: 7.1.375 / Virus Database: 267.14.23/243 - Release Date:
1/27/2006
--
No virus found in this outgoing message.
Checked
by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.23/243 -
Release Date: 1/27/2006