[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-msg] Confusion about RM location elements
I agree with As an additional piece of info regarding
location, attached are the guidelines Carl provided to us in May. I can’t
remember whether we reviewed / considered this when making decisions on
location. I’ll admit I have not taken the time recently to review this. Thanks, Tim From: Aymond,
Patti [mailto:Patti.Aymond@iem.com] Karen, The structure of these
elements haven’t been finalized, so the discrepancies persist. You’re message caused me
to pause and look seriously at the structure of these elements for the first
time. I’ve never really stopped to “think” about what these structures should
be. After taking a fresh look at this, I have a few suggestions for all of you
to consider. I’ve attached is a suggestion on the structure of the
ContactInformation and Location elements. A few key points are listed
below: 1) I suggest that we eliminate the “CIQInformation” element as a
complex structure. We can add a single sub-element to the ContactInformation
element (e.g. OtherContactInfo) of type ciq:xcil that can contain any of the
CIQ name, address, or other “party” information data. 2) The LocationType structure would include the three conditional
elements: LocationDescription (xsd:string), Address (ciq:xal), and TargetArea
(geo-oasis:where). Let me know what you
think. If everyone agrees, I will clean up the document before releasing a new
version with Rex’s updated ERMs. Patti Patti Iles
Aymond, PhD 8555
United From: Karen
Robinson [mailto:Karen.Robinson@nicta.com.au] Dear all, I’m in the process of
updating the RM message schemas and examples, and checking consistency with the
latest version of the matrix and data dictionary. I’m confused about the
location elements. The data dictionary lists the sub-elements of Location
as being: -
LocationDescription -
ExplicitAddress (with sub-elements ExplicitAddressScheme
& ExplicitAddressValue – both strings) -
TargetArea (with sub-elements Circle, Polygon, Country,
Subdivision, LocCodeUN – all strings) However, I was previously
under the impression that we were using a combination of CIQ addresses and the
OASIS GML profile? The CommonTypes schema lists the following as the
sub-elements of Location: -
Description -
CIQInformation (with sub-elements Party and Address –
probably only Address is needed in this context) -
geo-oasis:where (with sub-elements Point, LineString,
Polygon & Envelope) Could somebody please
clarify for me the latest decision about these elements? In my opinion,
if we are using CIQ for addresses in the ContactInformation package, we should
stick with CIQ addresses for Location, for the sake of consistency. Also,
representing circles, polygons, etc. with strings does not seem like a good
solution. The alternative is to use the OASIS GML profile – however this
has errors in it and does not seem to have been updated for a while (does
anyone know what is happening with this?). Thanks, Karen. IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE:
--
--
|
Best_Practices_-_a_GML_Profile_for_usein_OASIS_EM_Standards[1].doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]