[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-msg] Meeting Next Week?
Rex, That meeting time is fine with me, too. Renato will still be on leave next week, however. Thanks very much for sending the new ERM. I think that the way you have included ContactInformation at the ResourceMessage level makes sense (whereas the other alternatives you described - ContactInformation:char, ContactInformation:ContactInformation, ContactRole:ContactInformation - are not optimal, as you have pointed out). I can't see any other places where the entire ContactInformation package needs to be used, but I think the CIQInformation part of that package needs to be used within Location. That is, we need another element such as CIQLocation:CIQInformation, following the Description:char element. I just consulted the latest schemas, and there the element is just called CIQInformation. However, this raises the problem in the ERM of having an element and a class with the same name (as already seen with ContactInformation!), so we should probably rename one of them. While I am commenting on the ERM, I have a couple of other minor suggestions: - I think ReferenceID:char should be part of ResourceInformation rather than ResponseInformation, so that ids can be introduced initially in request messages and then referenced in the responses. We also discussed changing the name of this element (the latest version of the schema has a "ResourceInformationSequenceNumber" element as part of "ResourceInformation" and a "ReferenceSequenceNumber" as part of "ResponseInformation" - perhaps only the first is needed, however, if we use that same element in both request & response messages). - It would be great if the elements within ResourceMessage could be ordered consistently with the matrix and schema, for ease of readability. Similarly for the Resource and ResourceStatus elements. - There is a typo in the "TypeStructure" element within Resource - I thought I'd better point this out before it is duplicated 16 times. :) - The types of many of the elements are wrong - e.g., "Quantity" is shown as a char, and SentDateTime as a double. Perhaps it would be worthwhile to fix up the types before duplicating the ERM, too (to save work down the track). Thanks, Karen. -----Original Message----- From: Rex Brooks [mailto:firstname.lastname@example.org] Sent: Thursday, 4 January 2007 1:43 AM To: email@example.com Subject: [emergency-msg] Meeting Next Week? Hi Folks, We should have a meeting next week to get back in synch after the holidays. The TC , the IF SC and the Adoption SC are all meeting next Tuesday morning, so it would be crowded to squeeze our meeting into that set of timeslots, plus we need to include Karen and Renato, if he can manage it. So I suggest scheduling our next meeting for Thursday Jan 11 at 4:00 to 5:00 p.m. EST. If that doesn't work for you, please pipe up here and we can discuss it. If we don't hear from anyone with conflicts for this, I would appreciate it if Tim could schedule it for us. Also, I would appreciate it if anyone has a recollection of any other message elements where the ContactInformation package needs to be added other than the top level Resource Message unit for each message type and in the ResponsibleParty in OwnershipInformation. In the top level I used the form Contact:ContactInformation but I am wondering if it should just be ContactInformation: char since we don't have a message element: Contact? I hesitated to call it ContactRole, (the previous name for the relationship between the top level unit and the Contact Information cluste). I did that to avoid repeating an element from further downstream in the element chain. We may need a new label for the person sending the message, or responsible for sending the message (like MessageContact or MessageContactRole) to avoid having a term that is used in its own definition which would have if we used either ContactInformation:ContactInformation or ContactRole:ContactInformation (in which Contact Role is a defining characteristic with a specific list of types). I have attached my update of the main Element Reference Model so you can see what I have done. I didn't want to update all of the rest of the models until I am sure that this much is correctly aligned. I would also appreciate any discussion about whether we should consider adding the ContactInformation package to the ResponseInformation unit. My question is to those with more practical on-the-ground experience than I have as to whether or not a person other that the person sending a response type message would be the contact for that information. I certainly don't want to add wrinkles where we could get out of synch between the data dictionary, schema and models on the basis of my own speculation. Cheers, Rex -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309 -------------------------------------------------------------------------- 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.