OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

[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]