[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]