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] Meeting Next Week?


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

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


-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Thursday, 4 January 2007 1:43 AM
To: emergency-msg@lists.oasis-open.org
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

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.

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]