[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] FW: Suggestion: Add incidentKeyword tocontentObject
Excuse me, Please, if my memory has turned to swiss cheese, but 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. Cross-eyed with Alzheimer's, Rex At 2:17 PM -0500 1/30/06, Tim Grapes wrote: >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?). >------------------- > >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 ><mailto:tgrapes@evotecinc.com>tgrapes@evotecinc.com<mailto:tgrapes@evolutiontechinc.com> ><mailto:tim.grapes@associates.dhs.gov>tim.grapes@associates.dhs.gov > > >From: Aymond, Patti [mailto:Patti.Aymond@iem.com] >Sent: Monday, January 30, 2006 1:19 PM >To: Tim Grapes; Rex Brooks; emergency@lists.oasis-open.org >Subject: RE: [emergency] FW: Suggestion: Add incidentKeyword to contentObject > >Tim, > >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 > >Patti > > >From: Tim Grapes [mailto:tgrapes@evolutiontechinc.com] >Sent: Mon 1/30/2006 8:12 AM >To: 'Rex Brooks'; Aymond, Patti; emergency@lists.oasis-open.org >Subject: RE: [emergency] FW: Suggestion: Add incidentKeyword to contentObject >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>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>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><http://www.ieminc>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>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 > >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 > >-- >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 -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]