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: Minutes for Em-Msg Meeting -07-20-06


Hi Everyone,

Here are the Minutes of our last meeting,

EM-Msg Meeting July 20, 2006 Minutes

Roll:
Voting Members:
Rex Brooks,
Gary Ham,
Renato Iannella,
Patti Aymond,
Tom Merkle

We had a quorum, and the minutes for the previous meeting were accepted.

Agenda:

  1 We discovered that no one had managed to find the time to generate 
a sample message schema from the matrix, so we decided to go through 
the matrix, message by message, element by element to reach agreement 
on whether the elements are Mandatory (M), Conditional (C), Optional 
(O), or Not Applicable (N/A).

For the first message, Request Resource, we decided that:
TypeStructure should be Conditional (C) [and Mandatory (M) if 
ResourceID and Name are not present,]
TypInfo should be Optional (O),
Keyword should be Optional (O),
ResourceID should be Conditional (C) [and Mandatory (M) if 
TypeStructure and Name are not present], and
Name should be Conditional (C) [and Mandatory (M) if TypeStructure 
and ResourceID are not present] -- at least one of TypeStructure, 
ResourceID and Name is required for an identifier.

Jurisdiction was clarified as applying to the area to which the 
Request was sent, not the area from which the Request was generated, 
for the purpose of allowing a Request to be area specific in the case 
where a Resource could not be acquired within the given limitations 
from a more widespread area.

Availability was determined to be Optional (O), while Request 
Accept/Decline was determined to be Mandatory (M), meaning that:
if a Request is accepted, Availability is true, and
because Availability is true, a ResourceID is Mandatory (M), while
if a Request is declined, it means, in practical terms, that 
Availability is false, so no value for the Availability is required. 
(The Resource could be present but not available for distribution.)

Quantity was determined to be Conditional, for similar reasons, such 
that while a Resource might be present it could be unavailable, but 
if Availability is true, a value for Quantity is Mandatory (M).

These changes also applied to the second message, Response to Request 
except that ResourceID would be Mandatory(M) if  Availability is true.

  2 Having completed the first two messages, we decided that the 
remainder would likely be completed more quickly, so we asked for a 
volunteer to create a sample schema for either or both of the first 
two message types. Renato took up the challenge.

  3 We decided to meet again the next week on Thursday, July 27  at 
this same time to continue working through the message/element 
matrix, and perhaps, still complete the next version of the 
specification for a vote for public review in Mid August.

The meeting adjourned.

As always, please post comments, corrections and changes.

Cheers,
Rex
-- 
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]