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


 

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

 

--------------------------------------------------------------------------
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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]