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

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.


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