[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-msg] Draft schemas from the meeting
Hi Gary, I think the new schema looks good. The
definition of “LocationType” is now pretty much back to how it was
before, except for some differences with the min/maxOccurs. We probably still need to discuss it at
the teleconference, however – if everybody agrees that CIQInformation
needs to go back to being part of Location, the rest of the document (including
all of the ERMs) will need to be updated. Thanks, Karen. From:
Ham, Gary A [mailto:hamg@BATTELLE.ORG] Karen, NEVER intended the comment outs to be
permanent. Took them out so that I did not have to load all the
pieces to my Validator while building examples. The comment outs were
intended to stay or at least be fully discussed. Otherwise they would have
been deleted. We will certainly need them to determine the specific
CIQ pieces that we want to bring in. On the Location question, I was simply
trying to encapsulate CIQ from GML. But...... I certainly see your
logic. To the logical mind, a location has an address. It simply
makes sense, rather than making them co-equals as the current lay out
does. It is true, however, that not all Locations have an Address, but
that is not a problem if CIQInformation is optional. The difficulty
arises when an address is not necessarily associated with a reliable
location (e-mail address, Post office Box, Person Name, and radio
frequency are three examples). If I am not wrong, many of these
non-location "addresses" are handled
effectively CIQ. Many of these are appropriate entries in
ContactInformation as CIQInformation that is not associated with a physical
Location. So, I think that it is very necessary for us to build a
Contactinformation that addresses this fact. So, I guess I agree with you in
part. A Location should have an optional Attribute of
CIQInformation. (The updated draft Types Schema makes it so with exactly
one added line.) But ContactInformation should be able to contain
CIQInformation separately, without any reference to a Location
Element. Because....... As I read CIQ .... It can
certainly reside on its own with no reference to any geographical
location. So, I did not move the current CIQInformation Element down
underneath Location in the ContactInformationType, because it needs the ability
to stand on its own. Rather I simply put it in both places. It can
then be an element of a Contact without a Location, an element
of Contact Containing a non-CIQ Location, an element of a
Location that does use CIQ within a Contact, or an Element of a Location that
is not associated with a Contact at all. What do you think? 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 From:
Hi Gary (& others), The problem I see with treating Location
as just a container for GML information is that you lose the ability to capture
street addresses within the ScheduleInformation – unless you embed them
in the free-text “Description” element, which is not an optimal
solution. For example, we can no longer capture this sort of thing (from
the example in Section 3.3.1.4):
<ScheduleInformation scheduleType="RequestedArrival">
<DateTime>2006-03-24T09:00:00+10:00</DateTime>
<Location>
<Description>Innisfail Animal Refuge</Description>
<CIQInformation>
<xnal:Address>
<xnal:Country>
<xnal:Name>
</xnal:Country>
<xnal:AdministrativeArea>
<xnal:Name>QLD</xnal:Name>
</xnal:AdministrativeArea>
<xnal:Locality>
<xnal:Name>Innisfail</xnal:Name>
</xnal:Locality>
<xnal:Thoroughfare>
<xnal:NameElement>
<xnal:Number>27</xnal:Number>
</xnal:Thoroughfare>
<xnal:PostCode>
<xnal:Identifier>4860</xnal:Identifier>
</xnal:PostCode>
</xnal:Address>
</CIQInformation>
</Location>
</ScheduleInformation> I suppose we could connect the
ScheduleInformation and CIQInformation objects directly in the ERM (without
hanging CIQInformation off Location, as it was previously) – but to my
mind, grouping CIQ addresses under Location makes sense, because an address is
one valid way of specifying a Location (a GML Point is another, etc…). Unless I’m mistaken, the
ContactInformation captured at the ResourceMessage level captures only address
information for the resource requester, owner, etc. – it doesn’t
specify addresses for sending resources. By the way (a question for the whole
group), is it intentional that ContactInformation is now sitting up in the
corner of the ERM by itself, not connected to anything? It is a bit
confusing, as it doesn’t show where it fits into the message
structure. I noticed that the sub-elements of ContactInformation have
also been removed from all of the message tables. The schema layout looks fine to me –
however, I would uncomment quite a few of the comments. J Having worked
through a lot of message examples, I tend to think that most of the things that
have been removed are still needed. Thanks, Karen. From:
Ham, Gary A [mailto:hamg@BATTELLE.ORG] Karen, I agree with you on the need for the
committee to address CIQ content item specifically. And yes, I was just
looking for a "straw man" CIQ profile. But,
"Party" and "Address" fill that need for now. Are there
others that the committee wants? Should be a primary question for Thursday. The difference between CIQInformation and
Location was that Location is (at least in my mind) the container for the
GML structure and CIQ is the structure for addressing, party naming, etc.
following the OASIS spec for such data. So, in my mind, CIQ was not part
of Location, nor was Location part of CIQInformation. Rather both were
potential parts of ContactInformationType along with Radio, and a generic
Description. The objective was to put a place in for both
standards, without having to directly mix them. It was just my
personal interpretation. I am not hard over on it, though. If there is
reason to do differently, I think the committee would be open to it. I
certainly am. Can I take it from your comments that
the rest of the schema layout is OK with you? After the
"types" schema concept was your idea, and a good one. Keep the
input rolling!!!! Thanks, 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 From:
Hi Gary, Thanks for sending the schemas.
I’m a bit confused about what you want me to do with the CIQ
information. It looks like the “CIQInformationType” type I
added is still there, just commented out. Could we just uncomment it for
now and use it “as is” until we develop a CIQ profile consisting of
an appropriately restricted subset of CIQ? Or are you asking me to
actually develop the CIQ profile? Unfortunately, I doubt that I could work
out all of the potential parts of CIQ we might need by myself – I think
this is probably an activity for the group as a whole to tackle. So far,
I have identified “Party” and “Address” as potentially
useful parts of CIQ, but there must be other elements as well. One thing that confuses me about the
latest ERM and schema is why CIQInformation has been taken out of
LocationType. Previously, CIQ Addresses were the main way used to specify
location (they are used in most if not all of the message examples). Was
there some discussion at the face-to-face surrounding this? Regards, Karen. From:
Ham, Gary A [mailto:hamg@BATTELLE.ORG] Folks, The attached schema files represent a completed (with
clearly defined placeholders for CIQ and Location) reference schema for RM.
Based on For Karen, If you would like to specifically add the
CIQ piece to the Types Schema (and tidy as necessary) I would appreciate
it. For all, If your mail server strips off the attached files,
just respond to my email hamg@battelle.org
and I will send access to a file download capability. Respectfully, 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]