WBMM> Feedback and replies on Schedule schema

WBMM> Feedback and replies on Schedule schema

WBMM> Feedback and replies on Schedule schema

McDonald, Ira imcdonald at sharplabs.com
Wed Oct 1 22:37:03 EDT 2003


Hi folks,                                     Wednesday (1 October 2003)

The latest prototype of the Schedule schema is v0.20, available at:

    ftp://ftp.pwg.org/pub/pwg/wbmm/schemas/schedule-20030930.xsd

Some feedback from review of Schedule schema at today's WBMM telecon and
my tentative replies, for discussion at next Monday's WBMM face-to-face:

(1) Why did I start with the IETF Schedule MIB v2 (RFC 3231)?
    - because it contained almost all of the elements that we have ever
      proposed for content of a schedule in our WBMM discussions
    - Bill Wagner and Harry Lewis generally agreed at today's telecon
      (although they weren't familiar with the Schedule MIB)

(2) Why is 'SchedEntry' (row in a 'Schedule') a flat sequence, without
    typical PWG SM-style groups of elements in containers?
    - oops - because I didn't think of the container groups
    - I suggest a possible grouping later in this note

(3) Why are 'SchedDescription' and 'SchedState' bound to a single row,
    rather than being attributes of 'Schedule' (funny naming)?
    - oops - because I followed the SNMP-style naming
    - I suggest renaming 'SchedEntry' to 'ActionItem'
    - I suggest renaming the contained elements from 'SchedXxx...' to
      'ActionXxx...' or simply 'Xxx...' ('Operation' for example)

(4) Why aren't there some top-level elements of 'Schedule', besides
    the list of 'ActionItem'?
    - oops - because they weren't in the MIB and I didn't think of them
    - I suggest 'ScheduleDescription', 'ScheduleSourceURI', etc.

(5) Why don't we have an XML container definition for each separate
    operation that can be scheduled in an 'ActionItem', with the unique
    operation parameter signature explicitly defined?
    - oops - because it takes a lot of XML schema code
    - WSDL can't be used because these operations don't free-stand
    - I suggest I explore separate operations for the Schedule schema

(6) I suggest a revised Schedule model:
    (a) 'Schedule' contains
        - top-level elements ('ScheduleDescription', etc.)
        - 'ScheduleActionItems' (container of action items)
    (b) 'ActionItem' contains:
        - 'ActionStatus' (state, reasons, counters, etc.)
        - 'ActionDescription' (index, description, etc.)
        - 'ActionOperation' (container for 'Operation')
        - 'ActionCalendar' (period or calendar for action triggers)
    (c) 'Operation' contains:
        - 'OperationName' (type of operation)
        - 'OperationParameters' (container of XML or key/type/values)
        - 'OperationTargetURIs' (container of target services/devices)
        - 'OperationTargetObject' (name or URI of single target object)
        - 'OperationTargetElements' (container of target elements)
    <or>
    (c) 'Operation' contains:
        - a sequence of all possible separate operations, functioning as
          a 'switch()' statement to specify _one_ operation at a time
        - I prefer this model, it's just a lot of XML code

Comments?

Cheers,
- Ira McDonald
  High North Inc

PS - I will see email rarely, if at all, until next Monday morning.



More information about the Wims mailing list