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 Mtg 08-24-06


Hi Everyone,

Here are the Minutes of our last meeting, Please see PLEASE NOTE: below.

EM-Msg Meeting August 24, 2006 Minutes

Roll:
Voting Members:
Rex Brooks,
Tim Grapes,
PattiAymond,
Karen Anderson,
Tom Merkle


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


Agenda:

  1 We accepted the Meeting Notes from the previous meeting.
  2 We reviewed the ExampleMsgSemantics document Renato submitted and 
the list of Standard Resource Messages Patti included in the last 
update of the specification document.

We decided to combine the formats in a sample for a single 
MessageType so that a listing for the first message would begin as 
Section 3.2.1 Resource Request and be followed by 3.2.1.1. Overview 
and Description combining Renato's overview text and the descriptive 
text Patti assembled in the last version of the specification.

This would be followed by 3.2.1.2 Table of Message Elements as Renato 
developed, with the addition of a fifth column for the EDXL_DE 
Distribution Type associated with the MessageType from Patti's 
listing. This will incude the numbered Rules as shown in Renato's 
example.

This will be followed by 3.2.1.3.Message Flow per Renato's sample.

This will be followed by 3.2.1.4. Resource Request DOM/Reference 
Model (the name for which remains to be settled: see 3). We did not 
make a final decision on whether this model will be carried over for 
the final draft specification because we want to see how useful it 
will be and how we might divide up the total number of specification 
components for each MessageType, which is expanded considerably in 
this sample.

We also asked that an example .xsd XML Schema file be included in 
this first full sample for a specific Message Type. We did not decide 
that it should be included here or simply included with the other 
Message Schemata in a single complete .xsd for the entire 
specification, or if we should include each schema separately.

This set of work was handed off to Karen to work with Renato for the 
next meeting in two weeks (which as of now, would be scheduled to 
follow the TC meeting at 12:30 p.m. ET (US). PLEASE NOTE: We should 
probably reschedule this for another Thursday Afternoon session 
rather than ask Renato and Karen to attend a meeting at 2:30 a.m. ET 
Australian time. It should also be noted that the updating of the 
specification (not required for the next meeting) has now been handed 
off to Renato. We expressed our gratitutde to Karen to extend to 
Renato for taking on this set of tasks.

  3 Lastly, we discussed changing the name of the DOM to something 
like Reference Model and making it clearly understood that it is not 
intended to be used for generating program code, even though it could 
be translated into formal UML 2.0 and used that way. We tabled the 
discussion with the understanding that we need to double check that 
there is no OASIS requirement or mandate for including a DOM per se. 
No one seems to think that there is, but we want to be certain.

The meeting adjourned.
-- 
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]