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] Draft schemas from the meeting

Hi again,

In reviewing this, I noticed that I forgot to 
mention that I would also have to connect 
ContactInformation to Resource to be consistent 
so that the ResponsibleParty  is clearly also 
connected to ContactInformation. No biggie, just 
wanted to mention it.


At 6:56 AM -0500 12/14/06, Lee Tincher wrote:
>Funny Rex - in reading this string that was also my thought/preference - but
>I also do not feel strongly about it.
>'We the unwilling, led by the unknowing have been doing the difficult with
>little for so long that we are now ready to tackle the impossible with
>nothing.' -- Local Fire communications reserve volunteer motto
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>Sent: Wednesday, December 13, 2006 10:03 PM
>To: Karen Robinson; Ham, Gary A
>Cc: emergency-msg@lists.oasis-open.org
>Subject: RE: [emergency-msg] Draft schemas from the meeting
>It's probably not surprising that as the person
>making all those ERMs, I happen to disagree,
>though only with the notion of coupling
>ContactInformation with Location specifically.
>But I am not going to waste any time on insisting
>on it. I just think that reusable components are
>better left separated where they can be applied
>as needed. I don't think the logic to connect
>ContactInformation to Location is completely
>compelling. The part that gets tedious is that
>the individual ERMs are not simply copy-overs. I
>WOULD like to make sure that we think that we
>will keep it the way we change it, so I request
>everyone actually give it some thought.
>In terms of making it easier to change the ERMs,
>I can just create an association connector, with
>the correct cardinality value from the
>ContactInformation Class within the
>ContactInformation Package to the applicable
>class, e.g. the Location class or the
>ScheduleInformation class.
>At 10:47 AM +1100 12/14/06, Karen Robinson wrote:
>>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
>>From: Ham, Gary A [mailto:hamg@BATTELLE.ORG]
>>Sent: Thursday, 14 December 2006 6:07 AM
>>To: Karen Robinson
>>Cc: emergency-msg@lists.oasis-open.org
>>Subject: RE: [emergency-msg] Draft schemas from the meeting
>>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
>>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: Karen Robinson [mailto:Karen.Robinson@nicta.com.au]
>>Sent: Wednesday, December 13, 2006 1:07 AM
>>To: Ham, Gary A
>>Cc: emergency-msg@lists.oasis-open.org
>>Subject: RE: [emergency-msg] Draft schemas from the meeting
>>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
>>          <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>Australia</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>Downing
>>                              <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.
>>From: Ham, Gary A [mailto:hamg@BATTELLE.ORG]
>>Sent: Wednesday, 13 December 2006 12:46 AM
>>To: Karen Robinson
>>Cc: emergency-msg@lists.oasis-open.org
>>Subject: RE: [emergency-msg] Draft schemas from the meeting
>>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!!!!
>>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: Karen Robinson [mailto:Karen.Robinson@nicta.com.au]
>>Sent: Monday, December 11, 2006 10:13 PM
>>To: Ham, Gary A
>>Subject: RE: [emergency-msg] Draft schemas from the meeting
>>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?
>>From: Ham, Gary A [mailto:hamg@BATTELLE.ORG]
>>Sent: Tuesday, 12 December 2006 1:45 AM
>>To: emergency-msg@lists.oasis-open.org
>>Subject: [emergency-msg] Draft schemas from the meeting
>>The attached schema files represent a completed
>>(with clearly defined placeholders for CIQ and
>>Location) reference schema for RM. Based on
>>Karen Robinson's input, I broke it into two
>>files. The Types schema represents all data
>>structures that are unchanged across the
>>spectrum of messages. They may be used or not
>>use by a message, but they are unchanged where
>>they are used.  The only exception is
>>the likely further restriction of enumerated
>>types.  The reference schema is the base schema
>>for all RM messages.  It forms the least
>>restrictive schema from which each of the
>>messages will be derived.  I am working on each
>>of the messages, but they will be a lot simpler
>>because of Karen's input.
>>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
>><mailto:hamg@battelle.org>hamg@battelle.org and
>>I will send access to a file download capability.
>>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
>>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

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]