RE: [emergency-msg] GML and Resource

["Timothy Grapes" <tgrapes@evotecinc.com>]

Hi guys,

On the geo issue I had advised Gary to keep it simple (just use point) and
let public comment push more variation.  Although I am not aware of specific
requirements the practitioners did, however, express the need for
flexibility to express resource locations.  I don't think there's a right or
wrong approach going into public comment - so I'm OK with either - simple
and get comments or provide more options and live with the added complexity.

Regarding assignment I too am OK with the current design.  The practitioners
were also pretty clear that they are interested in one assignment.  Although
resource may in fact accept changing roles or assignments during an
incident, they did not wish to get into tracking all the stuff that happens
inside the incident.  Their scope of interest is getting resource in to an
incident, and then getting it back out.

(nope - no easy button for this stuff)
Thanks,

Tim


-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: Wednesday, February 07, 2007 12:43 PM
To: Aymond, Patti; Karen Robinson; Ham, Gary A;
emergency-msg@lists.oasis-open.org
Subject: RE: [emergency-msg] GML and Resource

Good points, Patti,

I think OriginatingSequenceNumber should be changed to 
PreceedingSequenceNumber. I think AssignmentInformaton is fine as is. 
I am not sure about AssignmentInformation multiplicity. Right now I'm 
thinking you can only have one assignment for one fully qualified set 
of a sequenced resource, but I'm not sure that degree of specificity 
is a good fit with fluid situations.

Cheers, (or maybe I should say "Ughh! this stuff still ain't any easier!"),
Rex

At 10:27 AM -0600 2/7/07, Aymond, Patti wrote:
>I personally like the 2nd option for the Address element. I've used 
>xal:AddressType and geo-oasis:WhereType in the latest version of the 
>specification.
>
>In working on the specification a few items for discussion came up:
>
>Should AssignmentInformation be a sub-element of Resource rather 
>than ResourceInformation? It seems to me that Quantity, PriceQuote, 
>as well as other assignment information should be resource specific 
>rather than at the ResourceInformation level.
>Should AssignmentInformation have multiplicity [0..*] rather than 
>the present multiplicity of [0..1]. This came to my mind when I 
>thought of different quantities of the same thing being assigned to 
>different locations.
>Since we've changed OriginatingMessageID to mean the first MessageID 
>in the message sequence, should we change OriginatingSequenceNumber 
>to PreceedingSequenceNumber so that it won't be mistaken for 
>the first SequenceNumber in the message sequence?
>Patti
>
>
>
>From: Karen Robinson [mailto:Karen.Robinson@nicta.com.au]
>Sent: Tue 2/6/2007 8:30 PM
>To: Ham, Gary A; emergency-msg@lists.oasis-open.org
>Subject: RE: [emergency-msg] GML and Resource
>
>
>Hi Gary et al,
>
>I don't have the answer to your main question (however my gut 
>feeling is that there may be valid reasons for using Envelopes or 
>Polygons, for example, and it is probably better to err on the side 
>of supporting too many options rather than too few).
>
>I have a comment on the types.  I assume the type of Address should 
>probably be "xal:AddressType" rather than "ciq:xal".  Also, does 
>anyone have an opinion on whether it is better to use the Address 
>element from the xal namespace, or to redefine it in our own 
>namespace?  In schema terms, this is the difference between 
>referencing the xal element or just reusing the type definition, 
>i.e.,:
>
>             <xsd:element ref="xal:Address" minOccurs="0" maxOccurs="1"/>
>OR
>             <xsd:element name="Address" type="xal:AddressType" 
>minOccurs="0" maxOccurs="1"/>
>
>The type of TargetArea should probably be "geo-oasis:WhereType", not 
>"geo-oasis:where".
>
>I'm confused about the new additions to the Data Dictionary in the 
>ContactInformation section.  Is the ContactLocation element 
>necessary, given that addresses are already incorporated into 
>xpil:Party?  Will it ever be necessary to give other location data 
>for the contact (e.g., a gml:Point?).  Also, I don't really like the 
>name "OtherContactInformation" for the CIQ party data.  How about an 
>element with name "Party" of type "xpil:PartyType" (& again we have 
>the choice of referencing the existing Party element in the xPIL 
>schema or redefining the element in our own namespace).
>
>Thanks,
>
>Karen.
>
>
>
>From: Ham, Gary A [mailto:hamg@BATTELLE.ORG]
>Sent: Wednesday, 7 February 2007 7:27 AM
>To: emergency-msg@lists.oasis-open.org
>Subject: [emergency-msg] GML and Resource
>
>Folks,
>
>I am trying to write the Data Dictionary reference for our 
>implementation of GML using geo-oasis.
>
>In our structure we have a "Location Type" consisting of three elements:
>1. LocationDescription:  xsd:string
>2. Address: ciq:xal
>3. TargetArea: geo-oasis:where
>
>My discussion will concern only number 3 on this list.
>
>The schema shows the TargetArea element to be of TargetAreaType from 
>the types schema.
>TargetAreaType should then be of type geo-oasis:WhereType.
>This is consistent with our other Types so I plan to make the Data 
>dictionary entries consistent with the schema.
>So far, no problem.
>
>Question: How broad do we want our location to be?
>
>An geo-oasis:whereType gives a choice of
>gml:Point
>gml:LineString
>gml:CircleByCenterPoint
>gml:Polygon
>gml:Envelope
>
>Did we mean to have Location have the option of all of these elements?
>Or should I make TargetAreaType a restriction on WhereType that 
>limits the choices to one or more of the options.
>
>I originally thought that Point would be simple and appropriate for 
>resource messages (the larger scope is certainly needed for future 
>updates to DE and CAP). But the name as TargetArea makes me think 
>the larger scope was intended by the committee for resource 
>messaging as well.
>
>Personal opinion: For resource, I would rather use Point. Too many 
>options already are making resource messages harder to deal with.   
>
>I need a consensus.
>
>
>R/s
>
>Gary A. Ham
>Senior Research Scientist
>Battelle Memorial Institute
>540-288-5611 (office)
>703-869-6241 (cell)
>"You would be surprised what you can accomplish when you do not care 
>who gets the credit." - Harry S. Truman
>
>IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE:
><http://www.iem.com/e_mail_confidentiality_notice.html>http://www..iem.com/
e_mail_confidentiality_notice.html
>-------------------------------------------------------------------------- 
>This email and any attachments may be confidential. They may contain 
>legally privileged information or copyright material. You should not 
>read, copy, use or disclose them without authorisation. If you are 
>not an intended recipient, please contact us at once by return email 
>and then delete both messages. We do not accept liability in 
>connection with computer virus, data corruption, delay, 
>interruption, unauthorised access or unauthorised amendment. This 
>notice should not be removed.


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.28/672 - Release Date: 2/6/2007
10:22 AM
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.28/672 - Release Date: 2/6/2007
10:22 AM