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: Minutes for Monday's Meeting

[NOTE: It still looks like the OASIS email servers is down, as these  
messages are not appearing in the archive]

> 2.3 We made a major change in the element RequestAcceptDecline,  
> which will be reflected in the DOM. RequestAcceptDecline is being  
> renamed Response and DeclineReason is being renamed ResponseReason.  
> These two elements are being placed into a new subelement of  
> ResourceInfo named RequestResponse. The enumerated list of values  
> for Response has expanded to include "Conditional" in addition to  
> the previously defined values "Accept" and "Decline". If Response  
> has a value of "Conditional", then "ResponseReason" is mandatory.  
> If Response has a value of "Accept" or "Decline" then  
> "ResponseReason" is optional.

A nicer way to represent this is within the "RequestResponse" there  
is one, and only one of:
  - Accept
  - Decline
  - Conditional

The latter contains a string indicating what the conditions are.

> 2.4 We made another major change which will be reflected in the DOM  
> in the elements in ResourceInfo related to schedule, These are  
> being collected together into a new subelement named  
> ResourceSchedule. These elements include RequestedArrivalDateTime,  
> AnticipatedReturnDateTime, AvailableDateTime, ComittedDateTime,  
> EstimatedDepartureDateTime, ActualDepartureDateTime,  
> EstimatedArrivalDateTime, and ActualDateTime.

Again, a nicer way to represent this is to say that there is a  
Schedule (of dates) and a Role that applies to those dates.
This will allow for more roles latter - instead of an never ending  
list of fooDateTime elements.

> 2.5 Elements needed by the firefighting community related to  
> resource ownership are being added in a subelement of ResourceInfo  
> named OwnerInfo. This element will contain the elements Owner,  
> HomeDispatch, and HomeUnit. All three of these elements are  
> Optional for the three message types that the SC has reviewed.

It would be good if we could generalise these. Can someone give an  

> 3 We had neither the time nor a sample message schema to review. It  
> is also, given the depth of the discussions we find necessary,  
> unlikely now that we will conclude the work necessary to produce  
> the next full working draft of the specification before the end of  
> August, unless the issues we uncover begin to decrease after we  
> take decisions such as those necessitated in this discussion.

We have examples instances in the "Information Model" document.

But it is pretty clear that as we look into the detail, the devil is  
showing ;-)

Cheers...  Renato Iannella
National ICT Australia (NICTA)

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]