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


Yup.

Rex

At 10:19 AM -0500 12/14/06, Ham, Gary A wrote:
>Which is why simply identifying ContactInformationType as the data Type
>of Contact and of Responsible Party is the correct way to do it in UML.
>No lines needed.
>
>
>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
>
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>Sent: Thursday, December 14, 2006 7:16 AM
>To: Lee Tincher; 'Rex Brooks'; 'Karen Robinson'; Ham, Gary A
>Cc: emergency-msg@lists.oasis-open.org
>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.
>
>
>Cheers,
>Rex
>
>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.
>>
>>Thanks,
>>Lee
>>'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.
>>
>>Cheers,
>>Rex
>>
>>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 updated.
>>>
>>>Thanks,
>>>
>>>Karen.
>>>
>>>
>>>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
>>>
>>>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: 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 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>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
>>St</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]
>>>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
>>>
>>>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: 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?
>>>
>>>Regards,
>>>Karen.
>>>
>>>
>>>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
>>>
>>>Folks,
>>>
>>>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.
>>>
>>>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
>>>
>>>----------------------------------------------------------------------
>>>---- 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
>
>
>--
>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]