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